This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] JNI performance improvements


>>>>> "graydon" == graydon hoare <graydon@redhat.com> writes:

graydon> remarkably, these two optimizations speed up JNI by about 15x (5x for
graydon> the first optimization, 3x for the second). our JNI is now slightly
graydon> faster than sun's: on my machine we spend 95ns/call vs. sun's 129ns,
graydon> accodring to bryce's benchmark (see bug 12957).

Great work.

graydon> the patch is against java-gui-branch, which is where I've committed
graydon> it, but it'd probably be good to copy over to trunk before 4.0
graydon> finishes up.

Yes, definitely.  BTW, put something like "Fixes PR libgcj/12957" into
the ChangeLog (and commit message), this will update bugzilla with
info about the commit.

graydon> -#define FRAME_SIZE 32
graydon> +#define FRAME_SIZE 16

I assume this makes a difference when clearing the frames?

graydon> +  // Flag to indicate some locals were allocated.
graydon> +  int allocated_p;

'bool' is clearer IMO, assuming it is performance neutral.

graydon> -  // Synchronize while we do the work.  This must match
graydon> -  // synchronization in some other functions that manipulate or use
graydon> -  // the nathash table.
graydon> -  JvSynchronize sync (global_ref_table);

I don't think this is safe.  One thread could be calling
RegisterNatives and updating the method lookup table while another
thread is doing a lookup.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]