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