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

Thomas Stüfe thomas.stuefe at gmail.com
Fri Jun 22 16:25:20 UTC 2018

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.


(one of us should change his name to make this less confusing :-)

> Thanks,
>   Thomas

More information about the hotspot-runtime-dev mailing list