In the name of performance, go for it. :) Vitaly
Sent from my phone On Dec 20, 2012 1:22 PM, "Aleksey Shipilev" <aleksey.shipi...@oracle.com> wrote: > 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 > implementation. > > Sorry for mudding the quiet waters. > > -Aleksey. > > (*) 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.shipi...@oracle.com <mailto:aleksey.shipi...@oracle.com>> > 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. > > > >
