Andrew Haley wrote: > Perhaps we need to define what we're really aiming at. > > I would have thought: > > 1. Correctness (well-defined on the platforms we care about.) > 2. Portability (to the platforms we care about.) > 3. Maintainability/Readability of code. > 4. Efficiency. > > Does anyone really disagree with these priorities?
Not me. > Okay, perhaps we need to agree what platforms we care about. Here are my votes... - We don't care about platforms that don't have 8 bit bytes or where typeof(jchar) != signed char. - We don't care about platforms where 'jlong' is insufficient to hold VM private data. E.g., on a platform with 128 bit pointers, then the VM must use a hash table or something to derive the actual pointer (or whatever it needs). I.e., we deem 64 bits enough to uniquely describe all unique VM-private data structures. - We don't use ``because it runs faster on my VM'' as evidence of being more efficient; It must run faster on ALL VM's for it to mean anything. - When there are non-obvious tradeoffs in efficiency (i.e., it's faster on some VMs, slower on others, or otherwise muddy) then we choose the option which is the most portable and/or generic. - Requiring the VM to specially recognize and not trace a "RawData" object pointer type decreases portability (having a "RawData" type that merely is a normal object holding a long does not). 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... ). 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. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
