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

[Roger Riggs]

Hi Andrew,

If to achieve the performance or functional goals of the JEP hotspot 
changes are needed
they should be mentioned (no details needed) in the JEP.
It helps the reader understand the scope and impact of the change.

Regards, Roger


On 11/08/2018 04: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