Red Hat JBoss Enterprise Application Platform (JBoss EAP) is written in Java, a popular, multi-platform and object-oriented programming language.
Java programs run on a Java Virtual Machine (JVM).
JBoss EAP system administrators should have a minimal understanding of how Java programs run within the JVM.
JBoss EAP 7.4 runs by using Java 1.8, Java 11, or Java 17.
Earlier JVMs, such as JDK 1.7, are no longer supported.
To see the complete list of supported JVM vendors and versions, see the references section.
One central feature of the Java programming language is that the JVM frees the memory space of the objects, when the object is not used anymore.
The developer does not need to deallocate the memory space that their program uses.
This process is called garbage collection.
The Java Garbage Collector
The JVM runs as a regular user-space process on the OS, and it strictly follows the memory limits defined by the OS.
The JVM uses the garbage collector to automatically deallocate unused Java data structures (objects) from the heap.
The different implementations of JVM offer different garbage collectors.
For example, if you are using the Red Hat OpenJDK implementation, then you can use the following garbage collectors:
Serial
CMS (deprecated)
G1 (default)
Parallel
Shenandoa
ZGC
To learn more about the different Java garbage collectors, see the references section.
Java Memory Model since Java 1.8
The memory of the Java Virtual Machine (JVM) can be categorized into two areas:
- Heap
A dynamically growing and shrinking block of memory where Java data structures (objects) from applications reside.
The eden space is where newly created objects reside.
If an object has a short life cycle, then it can be quickly garbage collected in the eden space.
The survivor spaces store the objects that have survived garbage collection cycles in the young generation.
There are usually two survivor spaces.
The tenured space stores objects that have survived multiple garbage collection cycles in the eden and the survivor spaces.
- Non-Heap
Native memory, consisting of the following memory regions:
The metaspace: The region that replaced the Java 7 permanent generation.
This memory space stores metadata about the Java classes loaded in memory.
The metaspace grows automatically when needed, unless you define a maximum by using the -XX:MaxMetaspaceSize JVM option.
The thread stack: each thread started by a Java program reserves a fixed amount of native memory for data structures in the thread.
The thread stack size is 1024 kilobytes in Red Hat Enterprise Linux, and other Linux operating systems.
You can modify the thread stack size by using the -Xss JVM option.
The code cache: this memory region stores the Java classes bytecode, which is transformed into native code that targets the platform where the JVM is running.
The native byte buffers: a region to store native buffers, which Java programmers can allocate.
Other small regions for native libraries loaded from Java Native Interface (JNI) and other JVM data.
There are numerous JVM options available to tune the behaviour of the JVM when managing memory.
The following list is a small subset of these options:
-Xms is used to denote the minimum heap size.
It must be less than or equal to the maximum heap size.
-Xmx defines the maximum heap size.
If the application allocates memory greater than the maximum heap size, then the JVM process triggers an out-of-memory (OOM) error.
-XX:MaxMetaspaceSize defines the maximum size of the metaspace region.
-XX:NewSize defines the size of the eden generation.
-Xss or -XX:ThreadStackSize defines the size of each Java thread stack.
Red Hat provides the JVM Options Configuration Tool to help you to define the JVM parameters depending on your environment characteristics.
See the references section to learn more about the JVM Options Configuration Tool.
The JVM Memory Options in JBoss EAP
Configuring the sizes of your JVM memory spaces appropriately can help avoid out-of-memory exceptions and also improve the performance of any application deployed in the application server.
Configuring the JVM is different for a standalone server versus servers in a managed domain:
In a standalone server, the installed JVM starts the server instance, and this process is responsible for determining the JVM settings.
In a managed domain, the host controller starts the server JVM processes.
Thus, the host controller is responsible for determining the JVM settings of each individual server.
Configuring the JVM Settings for a Standalone Server
The JVM memory settings for a standalone server are defined in the standalone.conf file in your JBOSS_HOME/binJAVA_OPTS variable are passed to the JVM process that is running the standalone server.
The following example defines the memory parameters for the JVM process, defined in the standalone.conf file:
# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m ..."
Within the double quotes of the JAVA_OPTS variable, you can edit, add, or delete any of the settings regarding the JVM memory and garbage collection options for your standalone server.
Changes to the JVM settings in standalone.conf require a server restart.
