RE: Classpath build process and VM-specific issues

[Jeroen Frijters]

Archie Cobbs wrote:
> 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.

IMHO, that is a flawed argument. RawData allows better performance (for
VMs that do extra work), byte[] actively prevents that. So the trade-off
is *marginally* better portability (byte[]) or the option of better
performance (RawData).

Not to mention the fact that RawData is a distinct type and opaque from
the Java side. The contents byte[] can be manipulated in Java, or a
completely wrong byte array could be passed. So I agree with Andrew and
Steve, that it is also a better option from a software engineering pov.

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

But the beauty of RawData is that you can use 32 bit pointers on 32 bit
platforms!

Regards,
Jeroen