RFR(M): 8204908: NVDIMM for POGC and G1GC - ReserveSpace.cpp changes are mostly eliminated/no collector specific code.

[Kharbas, Kishor]

Hi All,

Thank you for your valuable comments and feedback in this thread so far.
After taken in all the comments and reading thoroughly through the code, I feel that the complexity added to virtualSpace.cpp is due to lack of abstraction in VirtualSpace and at GC level. NV-DIMM size and file paths are being passed all the way to OS calls.
So I went back to the drawing board and created a high level design to remove all the pain points of current implementation. I have uploaded the design at http://cr.openjdk.java.net/~kkharbas/8202286/Design%20for%20JEP%20JDK-8202286.pdf
I would love to hear your feedback and suggestions. Once we get confidence in the design, I will work on the implementation.

PS: 
1. Vinay has transitioned to another team in Intel, so he won't be able to continue on this jep.
2. If you feel this should be part of JEP discussion thread, we can take it there.

Thanks and regards,
Kishor

> -----Original Message-----
> From: Thomas Stüfe [mailto:thomas.stuefe at gmail.com]
> Sent: Friday, June 22, 2018 9:25 AM
> To: Thomas Schatzl <thomas.schatzl at oracle.com>
> Cc: Awasthi, Vinay K <vinay.k.awasthi at intel.com>; Paul Su
> <paul.su at oracle.com>; hotspot-gc-dev at openjdk.java.net; Hotspot dev
> runtime <hotspot-runtime-dev at openjdk.java.net>; Viswanathan, Sandhya
> <sandhya.viswanathan at intel.com>; Aundhe, Shirish
> <shirish.aundhe at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>
> Subject: Re: RFR(M): 8204908: NVDIMM for POGC and G1GC -
> ReserveSpace.cpp changes are mostly eliminated/no collector specific code.
> 
> Hi Thomas,
> 
> On Fri, Jun 22, 2018 at 4:44 PM, Thomas Schatzl
> <thomas.schatzl at oracle.com> wrote:
> > Hi Thomas,
> >
> > On Tue, 2018-06-19 at 13:40 +0200, Thomas Stüfe wrote:
> >> Hi Vinay,
> >>
> >> On Mon, Jun 18, 2018 at 6:47 PM, Awasthi, Vinay K
> >> <vinay.k.awasthi at intel.com> wrote:
> >> > Hi Thomas,
> >> >
> >> > Os::commit_memory calls map_memory_to_file which is same as
> >> > os::reserve_memory.
> >> >
> >> > I am failing to see why os::reserve_memory can call
> >> > map_memory_to_file (i.e. tie it to mmap) but commit_memory can't...
> >> > Before this patch, commit_memory never dealt with incrementally
> >> > committing pages to device so there has to be a way to pass file
> >> > descriptor and offset. Windows has no such capability to manage
> >> > incremental commits. All other OSes do and that is why
> >> > map_memory_to_file is used (which by the way also works on
> >> > Windows).
> >>
> >> AIX uses System V shared memory by default, which follows a different
> >> allocation scheme (semantics more like Windows VirtualAlloc...
> >> calls).
> >>
> >> But my doubts are not limited to that one, see my earlier replies and
> >> those of others. It really makes sense to step back one step and
> >> discuss the JEP first.
> >>
> >
> > There is already a discussion thread as David mentioned
> > (http://mail.op
> > enjdk.java.net/pipermail/hotspot-gc-dev/2018-May/022092.html) that so
> > far nobody answered to.
> >
> 
> Ah, I thought he wanted to have the JEP discussed in the comments section
> of the JEP itself.
> 
> > I believe discussion about contents the JEP and the implementation
> > should be separate.
> >
> 
> makes sense.
> 
> > So far what I gathered from the responses to the implementation, the
> > proposed idea itself is not the issue here (allowing the use of NVDIMM
> > memory for parts of the heap for allowing the use of larger heaps to
> > improve overall performance; I am not saying that the text doesn't
> > need a bit more work :) ), but rather how an implementation of this
> > JEP should proceed.
> 
> I have no problem with adding NVDIMM support. I think it is a cool feature.
> 
> Also, the awkwardness off the memory management abstraction layer in
> hotspot has always been a sore point with me (I originally implemented the
> AIX mm layer in os_aix.cpp, and those are painful memories). So, I have a lot
> of sympathy for Vinays struggles. Unfortunately not much time atm, but I will
> respond to your mail.
> 
> >
> > Let's discuss the non-implementation stuff in that thread. Vinay or I
> > can repost the proposal email if you do not have it any more so that
> > answers will be in-thread.
> >
> 
> Okay, sounds good.
> 
> Thanks,
>   Thomas
> 
> (one of us should change his name to make this less confusing :-)
> 
> > Thanks,
> >   Thomas
> >