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: Bryce McKinlay <mckinlay at redhat dot com>
- Cc: graydon hoare <graydon at redhat dot com>, java-patches at gcc dot gnu dot org
- Date: 14 Jan 2005 10:09:15 -0700
- Subject: Re: [patch] JNI performance improvements
- References: <41E6080C.9090608@redhat.com> <41E7F97A.60701@redhat.com>
- Reply-to: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:
>> + if (env->bottom_locals != NULL)
>> + _Jv_Free (env->bottom_locals);
>> + _Jv_Free (env);
Bryce> Why don't we just GC-allocate these - ie _Jv_AllocBytes() ? Then we
Bryce> wouldn't need _Jv_FreeJNIEnv.
The Thread native data is not scanned by the GC. Neither is the
JNIEnv (so bottom_locals would always appear to be garbage).
I think we should finally expose a way to allocate conservatively
scanned memory. We can make it libgcj-only and not expose it to CNI.
If we ever do end up in the unlikely position of integrating a
non-conservative GC, we could just go through libgcj and change the 10
places using this API to register layout info instead.
If we did this, we could scan each frame in the JNIEnv. Then we could
get rid of the reference counting for local references, and associated
locking.
Tom