415
• -XX:MaxNewSize or -Xmn is specified: The maximum young
generation size is capped at 80% of available memory (25.6GB)
regardless of the amount specified.
• Users can use -XX:MaxRAM to let the VM know how much DRAM is
available for use. If specified, maximum young gen size is set to 80%
of the value in MaxRAM.
• Users can specify the percentage of DRAM to use, instead of the
default 80%, for young generation with
• -XX:MaxRAMPercentage.
• Enabling logging with the logging option gc+ergo=info will print the
maximum young generation size at startup.
Non-volatile Mapped Byte Buffers
JEP 352: Non-Volatile Mapped Byte Buffers [https://openjdk.java.net/jeps/352]
adds a new JDK-specific file mapping mode so that the FileChannel API can be used to
create MappedByteBuffer instances that refer to persistent memory. The feature should
be available in Java 14 when it is released, which is after the publication of this book.
This JEP proposes to upgrade MappedByteBuffer to support access to persistent
memory. The only API change required is a new enumeration employed by FileChannel
clients to request mapping of a file located on a DAX file system rather than a
conventional, file storage system. Recent changes to the MappedByteBufer API mean
that it supports all the behaviors needed to allow direct memory updates and provide
the durability guarantees needed for higher level, Java client libraries to implement
persistent data types (e.g., block file systems, journaled logs, persistent objects, etc.). The
implementations of FileChannel and MappedByteBuffer need revising to be aware of
this new backing type for the mapped file.
The primary goal of this JEP is to ensure that clients can access and update persistent
memory from a Java program efficiently and coherently. A key element of this goal is to
ensure that individual writes (or small groups of contiguous writes) to a buffer region can
be committed with minimal overhead, that is, to ensure that any changes which might
still be in cache are written back to memory.
Appendix d JAvA for persistent MeMory
• -XX:MaxNewSize or -Xmn is specified: The maximum young
generation size is capped at 80% of available memory (25.6GB)
regardless of the amount specified.
• Users can use -XX:MaxRAM to let the VM know how much DRAM is
available for use. If specified, maximum young gen size is set to 80%
of the value in MaxRAM.
• Users can specify the percentage of DRAM to use, instead of the
default 80%, for young generation with
• -XX:MaxRAMPercentage.
• Enabling logging with the logging option gc+ergo=info will print the
maximum young generation size at startup.
Non-volatile Mapped Byte Buffers
JEP 352: Non-Volatile Mapped Byte Buffers [https://openjdk.java.net/jeps/352]
adds a new JDK-specific file mapping mode so that the FileChannel API can be used to
create MappedByteBuffer instances that refer to persistent memory. The feature should
be available in Java 14 when it is released, which is after the publication of this book.
This JEP proposes to upgrade MappedByteBuffer to support access to persistent
memory. The only API change required is a new enumeration employed by FileChannel
clients to request mapping of a file located on a DAX file system rather than a
conventional, file storage system. Recent changes to the MappedByteBufer API mean
that it supports all the behaviors needed to allow direct memory updates and provide
the durability guarantees needed for higher level, Java client libraries to implement
persistent data types (e.g., block file systems, journaled logs, persistent objects, etc.). The
implementations of FileChannel and MappedByteBuffer need revising to be aware of
this new backing type for the mapped file.
The primary goal of this JEP is to ensure that clients can access and update persistent
memory from a Java program efficiently and coherently. A key element of this goal is to
ensure that individual writes (or small groups of contiguous writes) to a buffer region can
be committed with minimal overhead, that is, to ensure that any changes which might
still be in cache are written back to memory.
Appendix d JAvA for persistent MeMory