Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries

[Etienne M. Gagnon]

On Tue, Dec 03, 2002 at 07:05:46PM +0000, John Leuner wrote:
> > I don't see why we should add overhead to all JVMs because of a single
> > JVM that does not correctly implements JNI.
> 
> It's not JNI that is the problem, it is the GC mechanism.

Which means Kissme has a flawed JNI design, as JNI was *specifically*
designed to allow for:

 - concurrent collectors
 - moving collectors
 - stop-the-world collectors
 - whatever collector

without the need for any specific native code calls to make it possible.

So, yes, the symptom is a GC problem, but the real problem is a lack
of GC guards around Kissme internal JNI hooks, which is, in my mind, a
JNI implementation design flaw.

I do reiterate my suggestion to the Kissme team to merge their effort
with SableVM, which already has a robust and functional implementation
of such wrapers, as well as all the machinery for providing *precise*
garbage collection (i.e. GC maps, even for conveluted use of JSR/RET
within bytecode).

> > If Kissme-specific libraries are required, why not do like the CNI
> > code and provide separate source files for its libraries (in a
> > distinct file hierarchy in the Classpath CVS repository)?
> 
> This is possible, but then we risk divergence of code.

Not really, as this should be temporary; until Kissme's JNI/GC is
fixed.  Unless you are planning not to solve this problem in the not
too far future, of course.  But, then, it might still be a good idea
to keep a separate tree, as not to impose design choices to
Classpath's JNI code based on Kissme's constraints.

> I agree that any changes shouldn't require VM developers to do
> additional work to match the native interface. It also shouldn't have
> implications for what kind of JNI libraries will work with VMs.

So, you probably agree that adding an indirection for doing "blocking
calls" and providing VM-specific implementation of those calls is not
a good idea.

I should stress that my objective IS NOT to make life harder to Kissme
developers; it is only to make sure that Classpath's desing goals
remain to make the best VM-independent implementation of the Java
class libraries, and that the native JNI libraries remain completely
VM independent, as they should be.  This is what would be most
beneficial to all Free VMs based on Classpath.

Yet I think it can be a good idea to have *separate* VM-specific
native libraries (e.g. CNI) which can provide faster, simpler, or
whatever properties for specific VMs.

Thanks,

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

pgpFhvRAFEZlB.pgp
Description: PGP signature