RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
Derek.White at cavium.com
Thu Nov 8 16:20:57 UTC 2018
Thanks Andrew, looks great!
> -----Original Message-----
> From: Andrew Dinn <adinn at redhat.com>
> Sent: Thursday, November 08, 2018 11:01 AM
> To: White, Derek <Derek.White at cavium.com>; Vladimir Kozlov
> <vladimir.kozlov at oracle.com>; Alan Bateman <Alan.Bateman at oracle.com>
> Cc: Jonathan Halliday <jonathan.halliday at redhat.com>; hotspot-compiler-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-
> volatile memory
> External Email
> Hi Derek,
> On 08/11/18 15:49, White, Derek wrote:
> > 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).
> The prototype implements this on Linux/x86_64 and Linux/AArch64. On
> other platforms it will refuse to create a persistent MappedByteBuffer by
> throwing an exception.
> I believe it should be straightforward to migrate it to Windows/x86_64 but I
> don't know for sure. That depends on support for the mmap MAP_SYNC
> mode being available.
> I am not currently in a position to implement or test Windows/x86_64. I
> really don't know what would work on other hardware or OSes. I'd be happy
> to take advice but I'd like to get this included targeting the 2 OS/CPU
> configurations mentioned above and see those other platforms supported as
> an upgrade.
> I'll add a note to the JEP to record this.
> 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
More information about the hotspot-compiler-dev