How to Increase Heap Size in Java Virtual Machine?
There are two types of memory stack memory and heap memory. All the dynamic allocations go into heap memory and the rest of the static allocations and variables allocations go into stack memory. Whenever a java program is executed in the java virtual machine it uses the heap memory to manage the data. Task Engine runs on JVM (Java Virtual Machine). Hierarchy is pictorially shown below.
So now coming onto heap memory, the heap is a location in memory used by the Java Virtual Machine (JVM). The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated. The heap is created on a virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly reallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementer’s system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.
A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size. The following exceptional condition is associated with the heap whenever a computation requires more heap than can be made available by the automatic storage management system, the Java Virtual Machine throws an OutOfMemoryError.
By default, the JVM heap size is 1GB, which is usually enough to accommodate the data used by Task Engine. However, larger heap size may be required under some circumstances, for example, when the average size of the parameters in a task is very large. Under these circumstances, the following log item is recorded in Task Engine log files. If this log item appears regularly, you need to increase the heap size.
Now the question arises of how to increase the heap size of memory. So a common solution to it Now in order to change/increase the JVM heap size is made possible by using command-line options.
-Xms : To set an initial java heap size -Xmx : To set maximum java heap size -Xss : To set the Java thread stack size -Xmn : For setting the size of young generation, rest of the space goes for old generation
Procedure: To increase the Application Server JVM heap size
- Log in to the Application Server Administration Server.
- Navigate to the JVM options.
- Edit the -Xmx256m option.
- This option sets the JVM heap size.
- Set the -Xmx256m option to a higher value, such as Xmx1024m.
- Save the new setting.
Note:
The process to change the heap size of the Web Server is the same you just need to log in in Web Server Administration Server. After that process is the same. It is good practice for big production projects to set the minimum -Xms and maximum -Xmx heap sizes to the same value. For efficient garbage collection, the -Xmn value should be lower than the -Xmx value. Heap size does not determine the amount of memory your process uses.
4 Sizing the Generations
A number of parameters affect generation size. Figure 4-1, «Heap Parameters» illustrates the difference between committed space and virtual space in the heap. At initialization of the virtual machine, the entire space for the heap is reserved. The size of the space reserved can be specified with the -Xmx option. If the value of the -Xms parameter is smaller than the value of the -Xmx parameter, than not all of the space that is reserved is immediately committed to the virtual machine. The uncommitted space is labeled «virtual» in this figure. The different parts of the heap (tenured generation and young generation) can grow to the limit of the virtual space as needed.
Some of the parameters are ratios of one part of the heap to another. For example the parameter NewRatio denotes the relative size of the tenured generation to the young generation.
Figure 4-1 Heap Parameters
Description of «Figure 4-1 Heap Parameters»
Total Heap
The following discussion regarding growing and shrinking of the heap and default heap sizes does not apply to the parallel collector. (See the section Parallel Collector Ergonomics in Sizing the Generations for details on heap resizing and default heap sizes with the parallel collector.) However, the parameters that control the total size of the heap and the sizes of the generations do apply to the parallel collector.
The most important factor affecting garbage collection performance is total available memory. Because collections occur when generations fill up, throughput is inversely proportional to the amount of memory available.
By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. This target range is set as a percentage by the parameters -XX:MinHeapFreeRatio= and -XX:MaxHeapFreeRatio= , and the total size is bounded below by -Xms and above by -Xmx . The default parameters for the 64-bit Solaris operating system (SPARC Platform Edition) are shown in Table 4-1, «Default Parameters for 64-Bit Solaris Operating System»:
Table 4-1 Default Parameters for 64-Bit Solaris Operating System
With these parameters, if the percent of free space in a generation falls below 40%, then the generation will be expanded to maintain 40% free space, up to the maximum allowed size of the generation. Similarly, if the free space exceeds 70%, then the generation will be contracted so that only 70% of the space is free, subject to the minimum size of the generation.
As noted in Table 4-1, «Default Parameters for 64-Bit Solaris Operating System», the default maximum heap size is a value that is calculated by the JVM. The calculation used in Java SE for the parallel collector and the server JVM are now used for all the garbage collectors. Part of the calculation is an upper limit on the maximum heap size that is different for 32-bit platforms and 64-bit platforms. See the section Default Heap Size in The Parallel Collector. There is a similar calculation for the client JVM, which results in smaller maximum heap sizes than for the server JVM.
The following are general guidelines regarding heap sizes for server applications:
- Unless you have problems with pauses, try granting as much memory as possible to the virtual machine. The default size is often too small.
- Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice.
- In general, increase the memory as you increase the number of processors, since allocation can be parallelized.
The Young Generation
After total available memory, the second most influential factor affecting garbage collection performance is the proportion of the heap dedicated to the young generation. The bigger the young generation, the less often minor collections occur. However, for a bounded heap size, a larger young generation implies a smaller tenured generation, which will increase the frequency of major collections. The optimal choice depends on the lifetime distribution of the objects allocated by the application.
By default, the young generation size is controlled by the parameter NewRatio . For example, setting -XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one-fourth of the total heap size.
The parameters NewSize and MaxNewSize bound the young generation size from below and above. Setting these to the same value fixes the young generation, just as setting -Xms and -Xmx to the same value fixes the total heap size. This is useful for tuning the young generation at a finer granularity than the integral multiples allowed by NewRatio .
Survivor Space Sizing
You can use the parameter SurvivorRatio can be used to tune the size of the survivor spaces, but this is often not important for performance. For example, -XX:SurvivorRatio=6 sets the ratio between eden and a survivor space to 1:6. In other words, each survivor space will be one-sixth the size of eden, and thus one-eighth the size of the young generation (not one-seventh, because there are two survivor spaces).
If survivor spaces are too small, copying collection overflows directly into the tenured generation. If survivor spaces are too large, they will be uselessly empty. At each garbage collection, the virtual machine chooses a threshold number, which is the number times an object can be copied before it is tenured. This threshold is chosen to keep the survivors half full. The command line option -XX:+PrintTenuringDistribution (not available on all garbage collectors) can be used to show this threshold and the ages of objects in the new generation. It is also useful for observing the lifetime distribution of an application.
Table 4-2 Default Parameter Values for Survivor Space Sizing
Default Java Maximum Heap Size is changed for Java 8
The Maximum Java Heap Size (Xmx) is the maximum amount of memory that Java application can uses. A lower Xmx value will cause a decrease in performance due to JVM has to force frequent garbage collections in order to free up space, also if the Xmx value is lower than the amount of live data, it might trigger OutOfMemoryError. Customers can configure Xmx via JVM options -Xmx to optimize their Java application performance, but quite a lot of Java users never explicitly specify the -Xmx option, so in those cases the default Xmx has been used. The default values for Xmx is based on the physical memory of the machine.
In current OpenJ9 release 0.19:
For Java 11 and above
The Xmx value is 25% of the available memory with a maximum of 25 GB. However, where there is 2 GB or less of physical memory, the value set is 50% of available memory with a minimum value of 16 MB and a maximum value of 512 MB.
For Java 8
The Xmx value is half the available memory with a minimum of 16 MB and a maximum of 512 MB.
Changes to default Java Maximum Heap Size for Java 8
From OpenJ9 release 0.20, The default Java Maximum Heap Size (Xmx) is changed to be consistent with Java 11, so by default in Java 8, 25% physical memory up to 25GB for the Xmx will be expected. If you want to revert to the default setting in earlier releases of OpenJ9, use the -XX:+OriginalJDK8HeapSizeCompatibilityMode option.
-XX:[+/-]OriginalJDK8HeapSizeCompatibilityMode is new option for release 0.20, but it is deprecated and should only be used in case you want to keep earlier releases behavior of default Xmx.
Keep in mind this change only affect the behavior of the default Xmx in Java 8 and there is no change for Java 11 and above. the option -XX:[+/-]OriginalJDK8HeapSizeCompatibilityMode is also ignored in Java 11 and above.
Verify Maximum Heap Size
If you want to confirm maximum heap size for your OpenJ9 release in runtime, you can simply verify the default max heap size via -verbose:gc options. you can find out the result in initialized section of verbosegc.
For OpenJ9 Java8 release 0.19 or earler, On 4GB physicalMemory machine the default Xmx is 512MB.
For OpenJ9 Java8 release 0.20, On 4GB physical memory machine the default Xmx is 1GB.