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

Thomas Schatzl thomas.schatzl at oracle.com
Fri Jun 22 14:44:12 UTC 2018

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.

I believe discussion about contents the JEP and the implementation
should be separate.

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.

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.


More information about the hotspot-runtime-dev mailing list