Re: Proposal for changes to Classpath's JNI libraries

[Stephen Crawley]

> 
> --=-PTIn8/GFVSUCYMLluSsI
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> >   1)  Add a ./configure switch to enable some Kissme-specific JNI extensi=
> ons.
> >=20
> >   2)  Add #ifdefs to classpath/include/jni.h to enable Kissme-specific
> >       JNI functions at the end of the function table.  These include=20
> >       functions for entering and exiting Kissme GC points.
> 
> What implications does this have for the scenario where Classpath is
> built as a package (eg .rpm or .deb) and Kissme loads the shared
> libraries for native IO from this package?

Kissme will require a Classpath shared library that was compiled with
the Kissme JNI extensions.  

> Would the package have to be built with the kissme flag? 

Yes.  Classpath would need to be built with --enable-jni and
--enable-jni-kissme.

> Would it be
> possible to have Classpath generate two sets of native libraries? One
> would have the default functionality, the other would call the Kissme
> JNI functions to enter/exit GC points.

I see no technical reason why this couldn't be done.  However, this is a
bit hypothetical right now, because we don't have a Classpath .rpm or
.deb.  

If we get more developers on board for Kissme, we should be able to make
the VM codebase GC safe with a few months effort.  This would remove the
need for the Kissme-specific shared library.  

In the short term, we could include an appropriately built .so file into
any Kissme .deb or .rpm.

-- Steve