This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [patch] JNI performance improvements
- From: Tom Tromey <tromey at redhat dot com>
- To: graydon hoare <graydon at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: 13 Jan 2005 09:52:22 -0700
- Subject: Re: [patch] JNI performance improvements
- References: <41E6080C.9090608@redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "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