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

[David Holmes]

On 13/06/2018 4:11 PM, Thomas Stüfe wrote:
> Hi,
> 
> (adding hs-runtime)

Thanks for that Thomas.

I also had a cursory glance. This is not really a Request for Review 
(RFR) as suggested by the email subject but more a "request for 
comment". The JEP is still a draft and this is a long way from being in 
a form that could be integrated. As a POC/prototype this may be 
functional but it is far too intrusive to me to be considered as the 
final form for this kind of change. The level of abstraction seems 
wrong; the use of nvdimm is everywhere. Ideally I would have expected 
the use of an alternate memory device to be hidden behind the address 
range - ie you just point the old gen to the alternate memory device, 
mapping into a given address range for the process and it "just works". 
Perhaps that is naive thinking, but I would not have expected to see so 
much code that needs to know about the nature of the underlying memory. 
And if there are key differences in the nature of this memory that 
requires changes to the existing code then I'd expect to see suitable 
abstractions introduced for that.

Cheers,
David



> 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
>>
>>
>>
>>
>>
>>