On 01/17/2017 12:55 PM, Vitaly Davidovich wrote: > Atomicity of values isn't something I'd assume happens automatically. Word > tearing isn't observable from single threaded code.
On 01/17/2017 09:17 PM, Michael Barker wrote: > That was my understanding too. Normal load/stores on 32 bit JVMs would tear > 64 > bit values. Although, I think object references are guaranteed to be written > atomically. (Triggered by my pet peeve) Please don't confuse "access atomicity" and "word tearing". Access atomicity means reading/writing the value in full. Word tearing (at least per JLS 17.6) means that fields are considered distinct, and the read/write of one field cannot disturb neighbors. Speaking of access atomicity, the upcoming value types would probably be non-access-atomic by default too, because enforcing access atomicity for widths larger than a machine one is painful. volatile longs/doubles had it easy on 32-bit VMs with 64-bit FPUs, compared to what variable-len values would have to experience. Thanks, -Aleksey -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
