[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for changes to Classpath's JNI libraries
From: |
Stephen Crawley |
Subject: |
Re: Proposal for changes to Classpath's JNI libraries |
Date: |
Tue, 03 Dec 2002 10:21:52 +1000 |
>
> --=-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