JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Hans Boehm]

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.
>
> Andrew.
>
>