[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Classpath build process and VM-specific issues

From: Andrew Haley
Subject: Re: Classpath build process and VM-specific issues
Date: Thu, 8 Apr 2004 20:09:58 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]