> > --=-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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
