Re: Classpath build process and VM-specific issues

[Mark Wielaard]

Hi,

On Mon, 2004-03-29 at 16:47, Michael Koch wrote:
> Am Montag, 29. März 2004 17:12 schrieb Andrew Haley:
> > Archie Cobbs writes:
> [...]
> >  > Object is good because it is automatically the size of a pointer
> >  > on any platform. However, it has one significant disadvantage,
> >  > which is that you must special case all such fields in your
> >  > garbage collector (unless you have a conservative collector).
> >  > byte[] avoids this problem.
> >
> > Indeed, but so does long.  I suppose it's possible that on some weird
> > platform a pointer mat not fit in long.  In gcj was have a class
> > RawData, which we know points to something that isn't an Object and
> > isn't gcable.
> 
> Yes, gcj has gnu.gcj.RawData.
> 
> Classpath has gnu.classpath.RawData for the same purpose. It would be 
> really nice to unify this. I tried once but I saw its a lot of work 
> needed to change gnu.gcj.RawData to gnu.classpath.RawData (or 
> gnu.lang.RawData or whatever).

To be honest I think we should not have RawData in Classpath.
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). 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?

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part