JDK-8202286 : Allocation of old generation of Java heap on alternate memory devices
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-04-25
  • Updated: 2020-11-11
  • Resolved: 2018-12-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12 JDK 13
12 b26Fixed 13Fixed
Related Reports
Blocks :  
Blocks :  
CSR :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8204908 :  
JDK-8211424 :  
JDK-8211425 :  
JDK-8215730 :  
Enable an experimental feature in HotSpot JVM to allocate old generation of Java heap on an alternative memory device, such as NV-DIMM, specified by the user. The goal of this enhancement is to facilitate exploration of different use cases for new memory technologies with the possibility of dramatically large heap sizes at increased cost efficiencies.

With the availability of cheap NV-DIMM memory, future systems may be equipped with a heterogeneous memory architecture. Such an architecture, in addition to DRAM, will have one or more types of non-DRAM memory with different characteristics. NV-DIMMs such as Intel Persistent Memory are projected to have higher capacity as compared to DRAM. Java applications would like to take advantage of this capacity. The motivation behind this JEP is to provide an experimental feature to facilitate exploration of different use cases for these non-DRAM memories.

Operating systems today expose NV-DIMM memory devices through the file system. Examples are NTFS DAX mode and ext4 DAX. Memory-mapped files in these file systems bypass the file cache and provide a direct mapping of virtual memory to the physical memory on the device.

The idea is to allocate part of Heap memory in NV-DIMM and use it exclusively for old generation objects. The rest of the heap is mapped to DRAM and young generation objects are always placed here. This implementation would add a new experimental option, `-XX:AllocateOldGenAt=<path>`. `AllocateOldGenAt` takes a path to the file system where the device is mounted, and use it to create a temporary, nameless file to map part of heap to NV-DIMM. GCs to be supported are: G1 and ParallelScavenge.

At a higher level we need to test: 

1. Correct mapping of Old generation to specified NV-DIMM device and correct placement of young/old objects in corresponding memory spaces. 
2. No regression when this feature is not used. 
3. File which is created to map memory to NV-DIMM is protected by corrected permissions and ceases to exist on different termination conditions such as graceful termination, power failure, system shutdown, etc. 

Thank you Mark!

Thanks for the additional informaiton. Late enhancement request approved by Project Lead.

Latest webrevs: G1 GC: http://cr.openjdk.java.net/~kkharbas/8211425/webrev.18 Parallel GC (applies on G1 patch) : http://cr.openjdk.java.net/~kkharbas/8211424/8211424.webrev.14

Late Enhancement Request This enhancement has a low risk level. The design and implementation has been done in consultation with the GC team. It has gone through multiple review rounds with Sangheon Kim (sangheon.kim@oracle.com) and Stefan Johansson (stefan.johansson@oracle.com). This experimental feature is needed for platforms with Intel Optane DC Persistent Memory to facilitate exploration of different use cases for Java based application stacks and frameworks.

Hi Mark, We have designed and implemented the solution such that it has minimum impact on existing code - static and dynamic. Majority of the implementation is handled in derived classes. During initialization, based on whether this feature is enabled by command-line flag, the right classes are instantiated. In this review thread, Stefan and Sangheon have looked closely at the implementation and have suggested better abstractions. The patch implements all the suggested abstractions. http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-December/024336.html http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-December/024335.html We do not see impact on performance of SPECjbb2015 with patched JDK (feature not enabled) vs un-patched JDK. http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-December/024307.html

Can you say more about why you consider this change to be low risk? Pointers to review threads and/or webrevs would help.

Closed the old implementation sub-task and created two new sub-tasks for G1 and Parallel Scavenge implementation.

Based on Mark's comment, moved the issue to enhancement. (ps: there was 'could not complete.. ' error after confirmation page, but looks like the change is reflected in the issue)

Is a JEP really needed for this work? This seems like a straightforward enhancement to the feature already implemented in JEP 316 (Heap Allocation on Alternative Memory Devices). An enhancement with a release note to document the new option would be sufficient.