Re: Classpath build process and VM-specific issues

[Michael Koch]

Am Montag, 29. März 2004 17:12 schrieb Andrew Haley:
> Archie Cobbs writes:
>  > Andrew Haley wrote:
>  > >  > > > I would like the vmdata field type then to be VMClass not
>  > >  > > > Object.
>  > >  > >
>  > >  > > I disagree, as it imposes a restriction on what vmData
>  > >  > > actually is.  The most obvious implementation of vmData is
>  > >  > > to be a byte[] instance holding the byte of a native
>  > >  > > pointer to an internal VM non-moveable data structure.
>  > >  >
>  > >  > I'm glad to see we agree (although I don't think it's at all
>  > >  > obvious that it should be a byte[], not all VMs use native
>  > >  > code).
>  > >
>  > > Eeeh.  I can't imagine that either.  If there's a strong
>  > > argument for holding native pointer in a byte[] ?
>  >
>  > Here's my thinking on this topic. Warning: may not apply to you
>  > :-)
>  >
>  > 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).


Michael