RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

[Andrew Dinn]

Hi Vladimir,

On 08/11/18 18:07, Vladimir Kozlov wrote:
> Thank you, Andrew, for sending changes
> 
> I am fine with intrinsics general wording in JEP. I 'reviewed' JEP.

Excellent. Thank you very much. On to the next step . . .

> I have several questions and issues with proposed changes in Hotspot
> which needs to be discussed during changes review. My main question is -
> should new nodes be treated as global memory barriers (not only RAW
> memory)?

That's a very good question which I did consider and to which, I think,
I can offer not just one answer but two, although I may not be
understanding correctly what is involved here. Apologies if that is the
case. Also for the length of the reply and the 'on the one hand/on the
other hand' conclusions.

I chose to type the memory ops using the RAW slice because currently the
Unsafe intrinsic is only being used to write data /transactionally/ to a
MappedByteBuffer i.e. to RAW addresses. Clearly, in order to ensure that
RAW memory is persisted correctly it is necessary to ensure that other
RAW memory read and write operations do not get re-ordered around the
flushes.

However, in order to commit persistent writes, transactional clients
using this API must employ some form of thread synchronization. A commit
involves writing some control state to an area of memory that other
threads may also be trying to write concurrently. The control state
updates a shadow record to a committed record. Synchronization is
required to ensure that updates to this shared control state ar
serialised and, hence, retain consistency.

As a consequence, for the current purposes I believe it does not matter
if non-RAW memory operations are re-ordered around the RAW flush
operations. Reordering before commit should not affect any other
threads. The synchronization needed at commit should enforce
serialization of any re-ordered non-RAW and RAW writes that might have
occurred before the commit so that they are all visible at the point of
commit.

On the other hand ... if in future we want to use this same Unsafe
intirinsic to provide writeback guarantees for memory that is not of RAW
type -- say for persisting changes to klass metadata or, even, Java heap
objects in some future Java persistent programming model -- in that case
I think we would need to type the memory ops using a Bottom ptr slice.

Perhaps we should just go for the second option straight away?

> One suggestion I can give is to introduce a feature flag in java code
> which will be set by VM if platform can support the feature. Similar to
> COMPACT_STRINGS in JEP 254 Compact Strings:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/66a0e6b3ec1a/src/java.base/share/classes/java/lang/String.java#l195
That sounds like a good idea. I will take a look at it (I assume if I
grep around in the JVM code looking for COMPACT_STRINGS I will find out
where this field actually gets initialised?).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander