Re: Proposal for changes to Classpath's JNI libraries

[Stephen Crawley]

> Stephen Crawley wrote:
> 
> >
> > Those of you have been following the Kissme mailing list will know
> > that we've had a long-standing problem with Kissme garbage collection
> > and IO.  In a nutshell, the Kissme garbage collector can only run
> > when all threads are within a "GC point".  Normal Java code regularly
> > enters (and exits) GC points, and native code will get there eventually.
> 
> 
> As far as I understand one of basic concepts behind JNI, idea behind 
> local/global references mess one exactly meant to provide a help for gc. 
> Call to native method can be marked as safe (all call areas have to be 
> fully resolved to allow gc for upper frames). Inside JNI, nothing bad 
> can happen - all references to java objects are managed through JNI 
> itself, which is fully under your control.

I understand this.  Unfortunately it does not work for us at the moment
because Kissme's native methods do not "obey the rules", and are hence
not GC safe.

> Why careful design of JNI layer cannot solve the problem here ?

I'm sure it would have done, but that's not where we are at right
now.  We have a large amount of JVM code whose implementation we
cannot really trust.  To move forward in the short term, we need
to do something like this.  

> You cannot expect all people out there to write their JNI libraries 
> wrapping any potentially blocking calls into your calls (I'm talking 
> about third party libraries).

You are correct.  However, support for direct IO from third party JNI
libraries is not a high priority for us right now.

--  Steve