Re: Classpath build process and VM-specific issues

[Andrew Haley]

Michael Koch writes:
 > >
 > > To be honest I think we should not have RawData in Classpath.

The trouble with RawData (as it is used in gcj) is that it breaks the
Java type system.  Its bizarre semantics mean that you have something
that looks like an object reference but you can't use it as one.  You
can't convert it to an instance of Object, for example.  A garbage
collector can't inspect it.  A VM that doesn't expect this behaviour
might crash.  If we use RawData like that in Classpath, a VM may need
to be modified.  It might not even be possible.  For that reason, I
believe that we should not use RawData in Classpath, although some VM
implementors might choose to.

I think we need a better abstraction.  Perhaps a Pointer class that
may be subclassed to swtPeerPointer, nativeIntPointer, and so on.
That will get over the enormous and painful maintenance problem with
SWT, where you have no idea what type a pointer is, because everything
is implicily void*.  This is truly Evil.

If some VM implementers want to use a RawData reference as a raw
pointer, fine.  But IMO our reference JNI shouldn't.

 > > It is used in VMClass, but it seems no VM implementor actually likes
 > > how that is setup now. And it is used in some of the new nio
 > > implementation classes. But I have a hard time seeing how our
 > > reference JNI implementation will make use of it. All places where it
 > > is used have unimplemented native jni parts. How are you planning to
 > > use this? Maybe we could add state (a Object or byte[] field to the
 > > class) that holds the real data (== address).

Better.

 > > And some access method to get add the address it represents (that
 > > then might be optimized by a particular VM). But that would mean
 > > that it isn't the same type as the one from libgcj (or Ptr from
 > > kaffe) since those classes are not actually accessed through
 > > normal java code or through JNI, but handled specially through
 > > CNI or Kaffe native/vm code.
 > >
 > > As Andrew says we could maybe just use long if we want to store an
 > > address. Andrew also worked hard on getting SWT (Eclipse) 64 bit
 > > clean. What I have seen from the (huge) patch this was mainly done by
 > > turning addresses as stored by JNI from int to long. BTW, was this
 > > work ever accepted into Eclipse?
 > 
 > The RawData pointer will get the real address to a native memory region. 
 > It can be directly used and has always the pointer size of the 
 > platform.

Uh, I don't understand what you mean, sorry.  Why is a Java reference
the same size as a native pointer?  Perhaps I misunderstood you.

Andrew.