Re: Classpath build process and VM-specific issues

[Andrew Haley]

Archie Cobbs writes:
 > 
 > Note: by this logic byte[] is the most portable/generic way to hold
 > VM private data. It places no portability restrictions, only
 > (possibly) performance ones. However, I have yet to hear a
 > convincing argument that proves byte[] is slower than RawData (or
 > whatever) on ALL platforms.
 > 
 > E.g., take JC as an example. byte[] and "RawData containing long"
 > both require one "unwrap" to get the pointer. "RawData containing
 > long" wastes 4 bytes on 32-bit platforms, but byte[]->length also
 > costs 4 bytes, so size is a wash. byte[] is portable to 128 bit
 > platforms while "RawData containing long" is not (sure, probably
 > won't happen in my lifetime, but... ).

Am I the only one who cares about type checking?  :-)

 > Finally, "RawData as opaque
 > pointer" doesn't require any unwraping but does hit GC cycle time
 > severely as every object has to be check for being in this special
 > RawData class. So for JC byte[] is best.

We get away with this in GCJ because a pointer outside the heap is
ignored.  I would have thought that many other GCs do this too.

Andrew.