[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.
Andrew.
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09