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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
