Re: Classpath build process and VM-specific issues

[Michael Koch]

Am Montag, 5. April 2004 15:10 schrieb 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.

AFAIK a java refernce is a pointer and this pointer can point 
everywhere. Right ? Tell me when I'm wrong.


Michael