memory usage of byte[] ?

[Peter B. Kessler]

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.

			... peter

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 
> correctly.
> 
> Cheers,
> 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, ...
>>
>> -Ulf
>>
>>
>> Am 06.07.2008 03:35, David Holmes - Sun Microsystems schrieb:
>>> Ulf,
>>>
>>> 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
>>>
>>>
>>>
>>