Re: GC and JNI

Okehee Goh <[email protected]> writes:
> Hello,
> 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?

I think the mail message explained this explicitly -- handles are
considered live only for the length of the method invocation.

.pm


>  Thank you for your help in advance.
> 
>  Regards,
> 
>  Okehee
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Chris Dodd
> Sent: Thursday, May 29, 2003 1:22 PM
> To: Zoe C. H. Yu
> Cc: [email protected]
> 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.
> 
> Chris Dodd
> [email protected]
> 

-- 
Perry E. Metzger		[email protected]