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

[Vladimir Kozlov]

On 11/9/18 9:01 AM, Andrew Dinn wrote:
> 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?

To be safe I think it should be global memory. We can optimize it later if we find issues.

> 
>> 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?).

It is controlled by VM flag CompactStrings which is platform specific:
http://hg.openjdk.java.net/jdk/jdk/file/13266dac5fdb/src/hotspot/share/runtime/thread.cpp#l3550

Vladimir

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