java.nio.*Buffer read/write atomicity

Aleksey Shipilev aleksey.shipilev at
Thu Dec 20 18:22:35 UTC 2012

The astonishment comes from this:
  a. racy Unsafe.putInt(...) to byte[] is atomic*
  b. racy direct ByteBuffer.putInt(...) is atomic*
  c. racy heap ByteBuffer.putInt(...) is NOT!
  d. racy heap ByteBuffer.asIntBuffer().put(...) is NOT atomic again!

So then, the hacky code over the byte arrays appears more consistent
than public API, without any solid reason for that? Granted, we can
always put our fingers in our ears and sing "la-la-la, you were never
guaranteed that", but I would say this is surprising inconsistency. And
by the way direct ByteBuffers (inadvertently) deal with that, it's
obvious we can do the same for heap ByteBuffers.

I feel dumb for having to explain this, I should have probably publish
the CR with the change and advocate it helps performance, fixing the
atomicity issue under the cover. The atomicity does not have to be
spec'ed, but I would certainly vote for it for the equivalent

Sorry for mudding the quiet waters.


(*) subject to underlying hardware memory model, alignment, etc.

On 12/20/2012 10:03 PM, Vitaly Davidovich wrote:
> But why would there be astonishment/surprise here if it says it's not
> threadsafe? I guess that's the part I'm having trouble understanding.
> Sent from my phone
> On Dec 20, 2012 12:54 PM, "Aleksey Shipilev"
> <aleksey.shipilev at <mailto:aleksey.shipilev at>> wrote:
>     On 12/20/2012 09:49 PM, Vitaly Davidovich wrote:
>     > Just curious - what's the driver for this? Suppose it did have full
>     > width writes/reads - you still shouldn't use it in a data racey way
>     > since it's not spec'd to be threadsafe and you can only observe torn
>     > reads/writes if you access it without synchronization.
>     The driver is the infamous "principle of least astonishment", aided by
>     my purism. Java is remarkable in the way it deals with races, trying to
>     surprise the least when something breaks. I think the change that brings
>     in more consistency without sacrificing maintainability and/or
>     performance is the change we endorse, right?
>     -Aleksey.

More information about the core-libs-dev mailing list