memory usage of byte ?
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Sun Jul 6 19:36:38 PDT 2008
This may be just a historical relic now. The early Alpha architecture
21064 did not support access to sub-32-bit memory locations. I'm pretty
certain that at least one architecture made the atomicity of accesses
configurable via a control word in the processor - but I can't locate
details as to which one (may have been later Alpha). I did also google
something that indicated that the Cray allows word-tearing :)
Intel, PPC and Sparc all provide atomic accesses - though with Intel's
docs you have to read-between-the-lines a little in places.
Note that we also need aligned accesses to avoid word-tearing on many
architectures - but the VM is pretty rigorous about aligning everything
Ulf Zibis said the following on 07/07/08 01:08:
> This is an interesting detail.
> Do you know, which systems aren't able to access bytes atomically, and
> which are?
> Intel, AMD, ...
> Am 06.07.2008 03:35, David Holmes - Sun Microsystems schrieb:
>> Peter B. Kessler said the following on 07/06/08 06:26:
>>> Every object in the HotSpot JVM has a 2-word header, where the
>>> word size is 32-bits in the 32-bit JVM and 64-bits in the 64-bit
>>> JVM (duh). An array then has a word that holds the length of
>>> the array. Following that comes the data, in whatever size is
>>> appropriate: boolean and byte elements take 1 byte each, chars
>>> and shorts take 2 bytes, ints and floats take 4 bytes, and longs
>>> and doubles take 8 bytes. References to other objects take either
>>> 4 or 8 bytes depending on whether you are in a 32-bit JVM or a
>>> 64-bit one (with a twist with compressed oops).
>> Might I also point out, however, that the layout of arrays must
>> prevent word-tearing (JLS 3, Section 17.6). So if byte array elements
>> are actually bytes, then the implementation must be able to access
>> them atomically as bytes. On systems that don't support atomic access
>> to sub-word elements, all array elements would have to be word-sized.
>> David Holmes
More information about the hotspot-dev