Re: Classpath build process and VM-specific issues

[Archie Cobbs]

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