JEP draft: Support heap allocation on alternative memory devices
|Component||hotspot / gc|
|Reviewed by||Mikael Vidstedt|
|Endorsed by||Mikael Vidstedt, Vladimir Kozlov|
Add support for allocating the Java heap on an alternative memory device specified by the user.
With the availability of cheap NV-DIMM memories, future systems will be equipped with a heterogeneous memory architecture. One example of such NV-DIMM technology is Intel's 3D XPoint. Such a heterogeneous architecture, in addition to DRAM, would be comprised of one or more types of memory with different characteristics. Let's call it non-DRAM memory. The Java system needs to support non-DRAM memory in order for Java applications to benefit from it.
The JEP targets alternative memory devices which follow the same semantics as DRAM. Also operations such as atomic operations, will work the same way as on DRAM. Which means these memory devices can be used for allocation of Java heap in place of DRAM, facilitating users to use this memory for their data without any application code changes. All other memory structures such as the code heap, metaspace, thread stacks, etc will reside in the DRAM as is.
Some use-cases for this proposal are:
In multi-JVM deployments some JVMs such as daemons, services, etc. are lower priority than others. NV-DIMMs would potentially have higher access latency compared to DRAM. So low priority processes can use NV-DIMM memory for heap, allowing high priority processes to use more DRAM.
Java applications such as big data and in-memory databases have an ever increasing demand for memory. Such applications could use NV-DIMM for Java heap since NV-DIMMs would potentially have larger capacity at lower cost compared to DRAM.
This JEP proposes enabling users to allocate Java heap in non-DRAM memory. Presently there are operating systems which support such memory through a file system. Examples are NTFS DAX mode (https://channel9.msdn.com/events/build/2016/p470) and ext4 DAX (https://lwn.net/Articles/618064). Memory mapped files in these file systems bypass the page cache and provide direct mapping of virtual memory to physical memory on the device.
One way to implement the proposed feature would be to add a new flag such as - "-XX:AllocateHeapAt=
"-XX:HeapDir=". This flag would take a path to the file system and use memory mapping to achieve the desired result of allocating Java heap on the memory device.
It is worth mentioning that existing Java heap related flags such as -Xmx, -Xms, etc and garbage collection related flags won't change their semantics.
Also, it is imperative to maintain security of the Java applications. For that the implementation needs to make sure that whichever file(s) created in the file system are:
- Protected by correct permissions preventing other users from accessing it.
- Cease to exist after application terminates due to any possible scenario.
Testing will not necessarily require any special memory, it can be performed on in-memory file systems such as ramfs or tmpfs.
Test items :
Java heap allocation in the memory which is specified on the command line.
Correct initialization, execution and termination of Java application.
The aforementioned security criteria should be met.
No changes in application behavior.
All jtreg tests should pass.