Hi Andrew, Given that there is platform-specific code, it would be good to be clear which platforms you are intending to implement as part of this JEP, and which platforms will need others to step in to support. I'm quite happy with your plan, but I'd like to see more JEPs being clear about platform support (CPU and OS). - Derek
-----Original Message----- From: hotspot-compiler-dev <hotspot-compiler-dev- bounces@openjdk.java.net> On Behalf Of Andrew Dinn Sent: Thursday, November 08, 2018 4:10 AM To: Vladimir Kozlov <vladimir.kozlov@oracle.com>; Alan Bateman <Alan.Bateman@oracle.com> Cc: Jonathan Halliday <jonathan.halliday@redhat.com>; hotspot-compiler- dev@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non- volatile memory
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/cla sses/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/opt o/memnode.hpp.udiff.html
http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/share/opt o/library_call.cpp.udiff.html
Back end rules:
http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/aarch 64/aarch64.ad.udiff.html
http://cr.openjdk.java.net/~adinn/pmem/webrev.04/src/hotspot/cpu/x86/x 86_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/aarch 64/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/a ssembler_x86.cpp.udiff.html