JDK 9 proposal: allocating ByteBuffers on heterogeneous memory
hboehm at google.com
Fri Apr 1 20:12:00 UTC 2016
It seems like the second one is kind of this issue.
Atomics in buffers are not needed to cause problems. If a buffer on x86
were mapped write-through or write-coalescing, for example, I'm not at all
sure that signalling completion of a write to the buffer by setting a
separate volatile flag (outside the buffer) would work. On x86, there is
no fence before the volatile store, and I'm not at all sure what ordering
properties there are for a write-through or write-coalescing store followed
by a write-back-cacheable store. There has also been a tendency to replace
x86 MFENCE instructions following a volatile store, with an atomic
read-modify-write instruction. AFAICT, this is usually faster precisely
because it only orders write-back-cacheable accesses.
So far, the memory model effort has concentrated on the assumption that all
relevant memory is mapped write-back-cacheable (or whatever the standard
mode is for user-level memory). My impression is that anything else is
generally significantly less well specified, at all levels of the stack.
On Fri, Apr 1, 2016 at 10:40 AM, Andrew Haley <aph at redhat.com> wrote:
> On 04/01/2016 06:05 PM, David M. Lloyd wrote:
> > Without a resolution to https://bugs.openjdk.java.net/browse/JDK-8008240
> > (atomics for buffers) or
> > https://bugs.openjdk.java.net/browse/JDK-6476827 (memory consistency
> > properties of buffers), how meaningful is this?
> That's on the list of things to get fixed with VarHandles. It's worth
> discussing in this context. The probelm is that "memory" with odd
> semantics may not map well onto the JMM.
More information about the core-libs-dev