[gclist] GC and JNI
Fri, 11 Jul 2003 13:39:07 -0700
I just read this mail describing GC handle accessed by a native method.
I am curious that how a garbage collector is able to notice that GC handles
are not referenced by native methods. Does the garbage collect have to
maintain GC handles as a root set like global variables so that they can be
traced? But if so, those handles will be always considered as live. What can
be a solution?
Thank you for your help in advance.
From: firstname.lastname@example.org [mailto:email@example.com]On
Behalf Of Chris Dodd
Sent: Thursday, May 29, 2003 1:22 PM
To: Zoe C. H. Yu
Subject: Re: [gclist] GC and JNI
On Fri, 30 May 2003, Zoe C. H. Yu wrote:
> Java supports JNI. I would like to know how does Java's GC handle those
> objects created in the Java Native codes? Do those objects can only be
> reclaimed conservatively? Or they can be reclaimed precisely with
> compiler support? Thanks very much!
The JNI interface insulates the GC of the JVM from the native code and
vice versa. The native code can never see an actual pointer into the
GC heap -- instead, the JVM passes opaque handles to the native code that
cannot be directly dereferenced. To do anything with the handle, the native
code needs to call a JVM function (through the JNI interface) to actually
do the job.
The JVM keeps track of the handles it has passed to a native method and
cleans them up when the method finishes. If a native method wants to
keep a handle alive after it returns (to store in a global non-java
data structure for reference by later native method calls), it needs
to explicitly create a global handle (via JNI callback) and explicitly
destroy that global handle when its done.