Re: Classpath build process and VM-specific issues

[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.

 > I remember kaffe had a kaffe.util.Pointer reference type that did
 > this, and was specially recognized by the GC. Slightly better than
 > Object imho.

Yes, but you have to be very careful that such instances never leak
into application code.

Andrew.