classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Classpath build process and VM-specific issues


From: Andrew Haley
Subject: RE: Classpath build process and VM-specific issues
Date: Wed, 7 Apr 2004 11:42:08 +0100

Jeroen Frijters writes:
 > Andrew Haley wrote:
 > >  > "jbyte" must have a single platform-specific definition, as all
 > >  > JVMs on that platform should be able to execute the same JNI
 > >  > library code (no recompilation required).
 > > 
 > > I didn't know that.  Is that requirement documented anywhere?  I can't
 > > see how you'd do it on a machine with 32-bit and 64-bit modes, for
 > > example.
 > 
 > Platform = Machine + OS. I don't have any reference, but I believe that
 > Etienne is right in saying that the same library should be usuable with
 > all JVMs on a specific platform.

But it's not necessarily possible.  Clearly it's desirable, no
argument there.

 > > Clearly the highest performance comes from using a naked long.
 > 
 > No, the highest performance comes from using a platform specific
 > pointer.

 > I think that for a JIT it is easier to replace a typed object
 > reference with a native pointer then a long. That's why I'm very
 > much in favor of using RawData. It can even be abstract, that way
 > the JNI layer can allocate sub types that contain the appropriate
 > number of bits to contain a native pointer.
 > 
 > For example:
 > 
 > public abstract class RawData {}
 > 
 > public final class RawData32 extends RawData
 > {
 >   private int pointer;
 > }
 > 
 > public final class RawData64 extends RawData
 > {
 >   private long pointer;
 > }
 > 
 > All the Java code would ever see are RawData references, but the JNI
 > layer knows that all RawData references are actually 32 or 64 bit (or
 > whatever that platform requires).

This seems to be identical to my proposal.

I no longer understand what we're arguing about...

Andrew.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]