Re: Proposal for changes to Classpath's JNI libraries

[Stephen Crawley]

> On Mon, Dec 02, 2002 at 11:01:32PM +1000, Stephen Crawley wrote:
> > In theory, the fix is simple; perform all blocking syscalls from within
> > GC points.  In practice, Kissme uses the Classpath native libraries for
> > Java I/O.  Therefore, we must:
> > 
> >   EITHER implement our own native I/O libraries,
> > 
> >   OR make some Kissme-specific changes to the Classpath sourcecode base.
> 
> This is not true.  You simply need considers all JNI calls as GC
> points.  In other words, as soon as a thread enters native code, it is
> considered GC safe, as no reference can be directly touched by that
> thread (all references being hidden within native global/local
> reference black structures).  The important thing is to block such
> native thread if it ever calls back the JVM (through the JNIEnv
> function pointers) while GC is running.

In theory that is true.  In practice, there is a lot of cruft in the
Kissme native code.  According to John Leuner, the reason Kissme went 
to a GC point mechanism was that much of the Kissme VM and native code 
is NOT GC safe.  In the long term, we should fix this.  But frankly,
we don't have the resources right now.

> Even though these changes would be invisible to other VMs, I think it
> would be bad design for Kissme.  Have you considered what would happen
> if a "user supplied" JNI library contained a blocking call, or some
> kind of infinite loop without call-backs into the Kissme JVM?  Such a
> library would deadlock the Kissme JVM if GC was required on another
> thread.  Unless, of course, you had the intention to require users to
> make Kissme-specific calls around such things, which defeats the
> purpose of a "Standard native interface" (JNI).

I have considered this.  I think it is more important to get Kissme
working for pure Java code than it is to support user-supplied native
libraries.  I'm sure John would agree.

-- Steve