memory usage of byte ?
Peter B. Kessler
Peter.Kessler at Sun.COM
Sun Jul 6 21:48:09 PDT 2008
In addition to being rigorous about aligning things, we are also
careful not to use calls like memcpy(3C), which is spec'd to copy
by bytes, so one can see word-tearing if you are watching the
destination while someone is memcpy'ing into it: e.g., an array
of object references. That was _no_ fun to debug.
David Holmes - Sun Microsystems wrote:
> Hi Ulf,
> 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
> David Holmes
> 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