RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
vladimir.kozlov at oracle.com
Fri Nov 9 17:52:47 UTC 2018
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
> 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
> 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
> 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:
> 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:
> 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
More information about the core-libs-dev