[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Classpath build process and VM-specific issues
From: |
Jeroen Frijters |
Subject: |
RE: Classpath build process and VM-specific issues |
Date: |
Fri, 9 Apr 2004 10:31:56 +0200 |
Archie Cobbs wrote:
> 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.
IMHO, that is a flawed argument. RawData allows better performance (for
VMs that do extra work), byte[] actively prevents that. So the trade-off
is *marginally* better portability (byte[]) or the option of better
performance (RawData).
Not to mention the fact that RawData is a distinct type and opaque from
the Java side. The contents byte[] can be manipulated in Java, or a
completely wrong byte array could be passed. So I agree with Andrew and
Steve, that it is also a better option from a software engineering pov.
> 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.
But the beauty of RawData is that you can use 32 bit pointers on 32 bit
platforms!
Regards,
Jeroen
RE: Classpath build process and VM-specific issues, Jeroen Frijters, 2004/04/09
RE: Classpath build process and VM-specific issues,
Jeroen Frijters <=
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