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

Wed Sep 5 05:41:02 UTC 2018

Hi,
I have uploaded implementation for parallel scavenge at http://cr.openjdk.java.net/~kkharbas/8204908/webrev-8204908.00
Majority of the implementation is handled in two new files - adjoiningGenerationsForHeteroHeap.cpp and psFileBackedVirtualspace.cpp. Would love to hear your feedback and suggestions.

I will post G1 GC implementation in a few days.

Thanks
Kishor.

> -----Original Message-----
> From: sangheon.kim at oracle.com [mailto:sangheon.kim at oracle.com]
> Sent: Thursday, August 30, 2018 4:06 PM
> To: Kharbas, Kishor <kishor.kharbas at intel.com>; Thomas Stüfe
> <thomas.stuefe at gmail.com>; Thomas Schatzl
> <thomas.schatzl at oracle.com>
> Cc: 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>
> Subject: Re: RFR(M): 8204908: NVDIMM for POGC and G1GC -
> ReserveSpace.cpp changes are mostly eliminated/no collector specific code.
> 
> Hi Kishor,
> 
> On 8/30/18 11:55 AM, Kharbas, Kishor wrote:
> > Hi Sangheon,
> >
> > So far I don’t see a need to do so. I will post my implementation code
> today or tomorrow, if we see a need or any simplification by changing
> classes in VirtualSpace.hpp, we can discuss that.
> Okay.
> 
> Thanks,
> Sangheon
> 
> 
> >
> > Regards,
> > -Kishor
> >
> >> -----Original Message-----
> >> From: sangheon.kim at oracle.com [mailto:sangheon.kim at oracle.com]
> >> Sent: Wednesday, August 29, 2018 10:17 AM
> >> To: Kharbas, Kishor <kishor.kharbas at intel.com>; Thomas Stüfe
> >> <thomas.stuefe at gmail.com>; Thomas Schatzl
> <thomas.schatzl at oracle.com>
> >> Cc: 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>
> >> Subject: Re: RFR(M): 8204908: NVDIMM for POGC and G1GC -
> >> ReserveSpace.cpp changes are mostly eliminated/no collector specific
> code.
> >>
> >> Hi Kishor,
> >>
> >> On 8/29/18 9:52 AM, Kharbas, Kishor wrote:
> >>> Hi Sangheon,
> >>>
> >>> Thanks for reviewing the design.
> >>> Since the collectors do not use them for heap memory, I did not have
> >>> to override VirtualSpace
> >> Sorry, I meant ReservedSpace and its friends at
> >> share/memory/virtualspace.hpp.
> >>
> >> Thanks,
> >> Sangheon
> >>
> >>
> >>> -Kishor
> >>>> -----Original Message-----
> >>>> From: sangheon.kim at oracle.com [mailto:sangheon.kim at oracle.com]
> >>>> Sent: Tuesday, August 28, 2018 2:38 PM
> >>>> To: Kharbas, Kishor <kishor.kharbas at intel.com>; Thomas Stüfe
> >>>> <thomas.stuefe at gmail.com>; Thomas Schatzl
> >> <thomas.schatzl at oracle.com>
> >>>> Cc: 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>
> >>>> Subject: Re: RFR(M): 8204908: NVDIMM for POGC and G1GC -
> >>>> ReserveSpace.cpp changes are mostly eliminated/no collector
> >>>> specific
> >> code.
> >>>> Hi Kishor,
> >>>>
> >>>> On 8/21/18 10:57 AM, Kharbas, Kishor wrote:
> >>>>> 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.
> >>>> The design looks good to me.
> >>>> If you are planning to change VirtualSpace at
> >>>> share/memory/virtualspace.hpp, including it on the design document
> >>>> would be helpful too.
> >>>>
> >>>> Probably folks involved in the previous discussions would say
> >>>> whether the design well covers their concerns or not.
> >>>>
> >>>> Thanks,
> >>>> Sangheon
> >>>>
> >>>>
> >>>>> 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
> >>>>>>>