RFR(M): 8204908: NVDIMM for POGC and G1GC - ReserveSpace.cpp changes are mostly eliminated/no collector specific code.
david.holmes at oracle.com
Mon Jun 25 05:35:59 UTC 2018
Hi Thomas Schatzl (I was going to use Thomas S. but even that doesn't
disambiguate in this case :) )
On 23/06/2018 12:44 AM, Thomas Schatzl 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
>>> 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
>> AIX uses System V shared memory by default, which follows a different
>> allocation scheme (semantics more like Windows VirtualAlloc...
>> 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.
Eventually, but personally I think discussion of a prototype/POC
implementation is extremely premature when the JEP itself has not been
discussed. I expect the JEP discussion to cover higher-level design
issues (i.e the right abstraction layer) which would then guide the
> 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