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

[Vladimir Kozlov]

Thank you, Andrew, for sending changes

I am fine with intrinsics general wording in JEP. I 'reviewed' JEP.

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

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

Thanks,
Vladimir

On 11/8/18 1:10 AM, Andrew Dinn wrote:
> On 07/11/18 17:12, Vladimir Kozlov wrote:
>> I am Lead for Hotspot [1]. Alan is Group Lead for core libs and he gave
>> review already.
>>
>> I don't see any reference to Hotspot in JEP so I am not sure what to
>> review. Do you need any new optimizations/intrinsics in Hotspot for this
>> JEP?
> 
> Yes I do need some new intrinsics. I was not clear whether they needed
> to be documented in the JEP. Perhaps you could advise?
> 
> n.b. If you need to know what is being proposed in order to answer that
> I can point you at my prototype implementation. Details after the sig.
> 
>> You need to ask Alan or Brian Goetz (as Area Lead) for endorsement
>> before 'Submitting' JEP [2].
> 
> Ok, will do once I know whether details of the intrinsics have to be
> included. Thanks for your help.
> 
> 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
> 
> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< ---
> 
> The basic operation to persist ByteBuffer changes is provided via a new
> method of jdk.internal.misc.Unsafe which /is/ currently described in the
> JEP:
> 
>    public void writebackMemory(long address, long length)
> 
> My prototype implements this method using 3 intrinsics, a pre-writeback
> memory sync, a per-cache line force (executed in a loop) and a
> post-writeback memory sync.
> 
> I also added a native method which allows the (cpu-specific) cache line
> size to be retrieved at class init time.
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~adinn/pmem/webrev.04/
> 
> Unsafe changes:
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/java.base/share/classes/jdk/internal/misc/Unsafe.java.udiff.html
> 
> In the underlying implementation of the intrinsics there are 3
> corresponding new IR nodes, CacheWBNode, CacheWBPreSyncNode and
> CacheWBPostSyncNode. They are matched by processor-specific ad file
> rules to generate the required assembler
> 
> Intrinsics implementation:
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/share/opto/memnode.hpp.udiff.html
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/share/opto/library_call.cpp.udiff.html
> 
> Back end rules:
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/x86/x86_64.ad.udiff.html
> 
> Assembler changes:
> 
> The assembler implementations are fairly straightforward. There is no
> need for a pre sync on either AArch64 or x86_64. A post sync is always
> needed on AArch64. It may not be needed on x86 depending on what type of
> cache line flush the processor supports
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp.udiff.html
> 
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/x86/macroAssembler_x86.cpp.udiff.html
> 
> http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/x86/assembler_x86.cpp.udiff.html
>