RFR(M): 8204908: Allocation of Old generation of Java Heap on alternate memory devices.

[Thomas Stüfe]

Hi,

(adding hs-runtime)

had a cursory glance at the proposed changes. I am taken aback by the
amount of complexity added to ReservedSpace for what I understand is a
narrow experimental feature only benefiting 1-2 Operating Systems and
- I guess, the JEP is not really clear there - only x86 with certain
hardware configurations?

e.g. http://cr.openjdk.java.net/~kkharbas/8202286/webrev.00/share/memory/virtualspace.hpp.udiff.html

The source having zero comments does not really help either.

"The motivation behind this JEP is to provide an experimental feature
to facilitate exploration of different use cases for these non-DRAM
memories."

Ok, but does this really have to be upstream, in this form, to
experiment with it?

I am not objecting against this feature in general. But I am unhappy
about the monster ReservedSpace is turning into. IMHO before
increasing complexity even further this should be revamped, otherwise
it becomes too unwieldy to do anything with it. It already somehow
takes care of a number of huge pages ("_special" and "_alignment"),
implicit-null-checks-when-space-happens-to-be-used-as-part-of-java-heap
("_noaccess_prefix"), allocation at alternate file locations
("_fd_for_heap", introduced by you with 8190308).

You also added a new variant to os::commit_memory() which directly
goes down to mmap(). So far, for the most part, the
os::{reserve|commit}_memory APIs have been agnostic to the underlying
implementation. You pretty much tie it to mmap() now. This adds
implicit restrictions to the API we did not have before (e.g. will not
work if platform uses SysV shm APIs to implement these APIs).

Best Regards, Thomas


On Tue, Jun 12, 2018 at 9:32 PM, Awasthi, Vinay K
<vinay.k.awasthi at intel.com> wrote:
> Hello,
>
> I am requesting comments on POGC/G1GC supporting NVDIMM/DRAM heaps. When
> user supplies AllocateOldGenAt=<NVDIMM file path>, JVM divides heap into 2
> parts. First part is on NVDIMM where long living objects go (OldGen) and
> other part is on DRAM where short living objects reside(YoungGen). This is
> ONLY supported for G1GC and POGC collectors on Linux and Windows.
>
> On Windows, OldGen resizing is NOT supported. On Linux, for G1GC, OldGen
> resizing is not supported however for POGC it is. Heap residing on DRAM is
> supported for Windows and Linux for POGC and G1GC.
>
> JEP to support allocating Old generation on NV-DIMM -
> https://bugs.openjdk.java.net/browse/JDK-8202286
>
> Patch is at http://cr.openjdk.java.net/~kkharbas/8202286/webrev.00/
>
> SpecJbb2005/SpecJbb2015 etc. are passing with this patch and one can test
> this by simply mounting tmpfs of certain size and pass that as an argument
> to AllocateOldGenAt.
>
> For G1GC, G1MaxNewSizePercent controls how much of total heap will reside on
> DRAM. Rest of the heap then goes to NVDIMM.
>
> For POGC, MaxNewSize decides the DRAM residing young gen size. Rest is
> mounted on NVDIMM.
>
> In all these implementations, JVM ends up reserving more than initial size
> determined by ergonomics (never more than Xmx). JVM displays these messages
> and shows NVDIMM and DRAM reserved bytes.
>
> Thanks,
>
> Vinay
>
>
>
>
>
>