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-
> boun...@openjdk.java.net> On Behalf Of Andrew Dinn
> Sent: Thursday, November 08, 2018 4:10 AM
> To: Vladimir Kozlov <vladimir.koz...@oracle.com>; Alan Bateman
> <alan.bate...@oracle.com>
> Cc: Jonathan Halliday <jonathan.halli...@redhat.com>; hotspot-compiler-
> d...@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
