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
