Java option heap size

Java option heap size

The two most important factors affecting garbage collection performance are total available memory and proportion of the heap dedicated to the young generation.

Total Heap

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.

The following discussion regarding growing and shrinking of the heap, the heap layout, and default values uses the serial collector as an example. While the other collectors use similar mechanisms, the details presented here may not apply to other collectors. Refer to the respective topics for similar information for the other collectors.

Heap Options Affecting Generation Size

A number of options affects generation size. Figure 4-1 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, then not all of the space that’s reserved is immediately committed to the virtual machine. The uncommitted space is labeled «virtual» in this figure. The different parts of the heap, that is, the old 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 –XX:NewRatio denotes the relative size of the old generation to the young generation.

Description of «Figure 4-1 Heap Options»

Default Option Values for Heap Size

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 options -XX:MinHeapFreeRatio= and -XX:MaxHeapFreeRatio= , and the total size is bounded below by –Xms and above by –Xmx . The default options for the 64-bit Solaris operating system (SPARC Platform Edition) are shown in Table 4-1.

Table 4-1 Default Options for 64-Bit Solaris Operating System

With these options, if the percent of free space in a generation falls below 40%, then the generation expands to maintain 40% free space, up to the maximum allowed size of the generation. Similarly, if the free space exceeds 70%, then the generation contracts so that only 70% of the space is free, subject to the minimum size of the generation.

As noted in Table 4-1, the default maximum heap size is a value that’s calculated by the JVM. The calculation used in Java SE for the Parallel collector are now used for all the garbage collectors. Part of the calculation is an upper limit on the maximum heap size for 64-bit platforms. See Parallel Collector Default Heap Size. There’s 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, because allocation can be made parallel.

Conserving Dynamic Footprint by Minimizing Java Heap Size

If you need to minimize the dynamic memory footprint (the maximum RAM consumed during execution) for your application, then you can do this by minimizing the Java heap size. Java SE Embedded applications may require this.

Minimize Java heap size by lowering the values of the options -XX:MaxHeapFreeRatio (default value is 70%) and -XX:MinHeapFreeRatio (default value is 40%) with the command-line options -XX:MaxHeapFreeRatio and -XX:MinHeapFreeRatio . Lowering -XX:MaxHeapFreeRatio to as low as 10% and -XX:MinHeapFreeRatio has shown to successfully reduce the heap size without too much performance degradation; however, results may vary greatly depending on your application. Try different values for these parameters until they’re as low as possible, yet still retain acceptable performance.

In addition, you can specify -XX:-ShrinkHeapInSteps , which immediately reduces the Java heap to the target size (specified by the parameter -XX:MaxHeapFreeRatio ). You may encounter performance degradation with this setting. By default, the Java runtime incrementally reduces the Java heap to the target size; this process requires multiple garbage collection cycles.

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 old generation, which will increase the frequency of major collections. The optimal choice depends on the lifetime distribution of the objects allocated by the application.

Young Generation Size Options

By default, the young generation size is controlled by the option -XX:NewRatio .

For example, setting -XX:NewRatio=3 means that the ratio between the young and old 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 options -XX:NewSize and -XX: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 -XX:NewRatio .

Survivor Space Sizing

You can use the option -XX:SurvivorRatio to tune the size of the survivor spaces, but often this isn’t 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 of the size of eden, and thus one-eighth of the size of the young generation (not one-seventh, because there are two survivor spaces).

If survivor spaces are too small, then the copying collection overflows directly into the old generation. If survivor spaces are too large, then they are uselessly empty. At each garbage collection, the virtual machine chooses a threshold number, which is the number of times an object can be copied before it’s old. This threshold is chosen to keep the survivors half full. You can use the log configuration -Xlog:gc,age can be used to show this threshold and the ages of objects in the new generation. It’s also useful for observing the lifetime distribution of an application.

Table 4-2 provides the default values for 64-bit Solaris.

Table 4-2 Default Option Values for Survivor Space Sizing

Источник

How to control Java heap size (memory) allocation (xmx, xms)

Java/Scala memory FAQ: How do I control the amount of memory my Java program uses (i.e., Java RAM usage)?

Java RAM: Short answer

The short answer is that you use these java command-line parameters to help control the RAM use of application:

• Use -Xmx to specify the maximum heap size
• Use -Xms to specify the initial Java heap size
• Use -Xss to set the Java thread stack size

Use this syntax to specify the amount of memory the JVM should use:

-Xms64m or -Xms64M // 64 megabytes -Xmx1g or -Xmx1G // 1 gigabyte

A complete java command looks like this:

See the rest of this article for more details. Also see my Java heap and stack definitions if you’re not comfortable with those terms.

Java RAM: The longer answer

As a bit of background, I’m running a Java application on a Raspberry Pi device where memory is limited. Unfortunately, every time I try to run the program I get this Java heap size error message:

“Error occurred during initialization of VM. Could not reserve enough space for object heap. Could not create the Java virtual machine.”

I knew my program doesn’t need a lot of memory — it was just hitting a database and generating some files and reports — so I got around this memory limit problem by specifying the maximum Java heap size my program was allowed to allocate. In my case I didn’t think about it too hard and just chose a heap size limit of 64 MB RAM, and after I set this RAM limit my program ran fine.

Setting the maximum Java heap size (Xmx)

You set the maximum Java heap size of your program using the -Xmx option to the Java interpreter. To specifically limit your heap size to 64 MB the option should be specified like this:

Using that memory limit setting, the Java command I use in my shell script to start my Java program looks like this:

where THE_CLASSPATH and PROGRAM_NAME are variables set earlier in my script. (The important part here is the -Xmx64m portion of the command.)

More Java memory-related command line arguments

You can find more options for controlling Java application memory use by looking at the output of the java -X command. Here’s what the output of those commands looks like from my JVM:

$ java -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath: set search path for bootstrap classes and resources -Xbootclasspath/a: append to end of bootstrap class path -Xbootclasspath/p: prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xloggc: log GC status to a file with time stamps -Xbatch disable background compilation -Xms set initial Java heap size -Xmx set maximum Java heap size -Xss set java thread stack size -Xprof output cpu profiling data -Xfuture enable strictest checks, anticipating future default -Xrs reduce use of OS signals by Java/VM (see documentation) -Xdock:name= override default application name displayed in dock -Xdock:icon= override default icon displayed in dock -Xcheck:jni perform additional checks for JNI functions -Xshare:off do not attempt to use shared class data -Xshare:auto use shared class data if possible (default) -Xshare:on require using shared class data, otherwise fail. The -X options are non-standard and subject to change without notice. 

From that list, the command-line arguments specifically related to Java application memory use are:

-Xnoclassgc disable class garbage collection -Xms set initial Java heap size -Xmx set maximum Java heap size -Xss set java thread stack size 

Java heap size descriptions (xms, xmx, xmn)

Digging around, I just found this additional Java xms , xmx , and xmn information on Apple’s web site:

-Xms size in bytes Sets the initial size of the Java heap. The default size is 2097152 (2MB). The values must be a multiple of, and greater than, 1024 bytes (1KB). (The -server flag increases the default size to 32M.) -Xmn size in bytes Sets the initial Java heap size for the Eden generation. The default value is 640K. (The -server flag increases the default size to 2M.) -Xmx size in bytes Sets the maximum size to which the Java heap can grow. The default size is 64M. (The -server flag increases the default size to 128M.) The maximum heap limit is about 2 GB (2048MB).

Java memory arguments (xms, xmx, xmn) formatting (MB, GB)

When setting the Java heap size, you should specify your memory argument using one of the letters “m” or “M” for MB, or “g” or “G” for GB. Your setting won’t work if you specify “MB” or “GB.” Valid arguments look like this:

Also, make sure you just use whole numbers when specifying your arguments. Using -Xmx512m is a valid option, but -Xmx0.5g will cause an error.

Источник