Re: Classpath build process and VM-specific issues

[Michael Koch]

Am Sonntag, 4. April 2004 16:15 schrieb 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?

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. There will never be problems on platforms with more then 64 
bit. Its really simply. Its just not done in classpath yet because I 
developed NIO on gcj so far. This hopefully changes now. (JamVM, be my 
friend ...).


Michael