JVM tuning
This product requires a Java virtual machine (JVM) to run and to support the Java applications deployed to the server. You can configure this product to enhance system use of the JVM. The JVM provides the runtime execution environment for Java based applications.
To configure any of these parameters, edit eclipse.ini. This file is located in the product installation directory.
| Parameter | Default setting | Description |
|---|---|---|
| -Xmx | -Xmx1024m | This setting controls the maximum size of the Java heap. Properly tuning this parameter can reduce the overhead of garbage collection, improving response time and throughput. The -Xmx parameter limits the amount of memory that the Java heap can allocate. The default for this product is set to 1GB so that your development environment can handle large complex workspaces. You can reduce -Xmx; however, it is not recommended to go below -Xmx512M. This product will fail with OutOfMemoryError if -Xmx is set too low. Tip: To avoid an artificial OutOfMemoryError
error message, use -Xmaf and -Xminf before changing -Xmx.
|
| -Xmaxf | -Xmaxf0.6 | This setting controls the maximum free space after garbage collection. The -Xmaxf parameter controls how the heap is expanded. The default for this product is set to -Xmaxf0.6. -Xmaxf0.6 instructs the JVM to compact the heap if the amount of free space exceeds 60%. Setting -Xmaxf to lower than 0.6 will make your heaps smaller; however, the JVM will perform more garbage collections. |
| -Xminf | -Xminf0.3 | This setting controls the minimum free space after garbage collection. The -Xminf parameter controls minimum free space in the heap. The default for this product is set to-Xminf0.3. -Xminf0.3 instructs the JVM to expand the heap, if after performing garbage collection it does not have at least 30% free space. |
If your system has problems with memory try setting the parameters to -Xmaxf0.4 -Xminf0.2 or to the more aggressive limits of -Xmaxf0.2 -Xminf0.1.
To reduce memory automatically, refer to Reducing memory.
Heap expansion occurs after garbage collection while exclusive access of the virtual machine is still held. The heap is expanded in a set of specific situations.
- The Garbage Collector (GC) did not free enough storage to satisfy the allocation request.
- Free space is less than the minimum free space. The minimum free space is set using the -Xminf parameter. The default is 30%.
- Garbage collection takes more time than the maximum time threshold. The time threshold is set using the -Xmaxt parameter. The default is 13%.
For more information, refer to Heap expansion.
Heap shrinkage occurs after garbage collection while exclusive access of the virtual machine is still held. Shrinkage does not occur in a set of specific situations. Also, there is a situation where a compaction occurs before the shrink.
- The Garbage Collector (GC) did not free enough space to satisfy the allocation request.
- The maximum free space, which can be set by the -Xmaxf parameter (default is 60%), is set to 100%.
- The heap has been expanded in the last three garbage collections.
- This is a System.gc() and the amount of free space at the beginning of the garbage collection was less than -Xminf (default is 30%) of the live part of the heap.
- If none of the above is true and more than -Xmaxf free space exists, the GC must calculate how much to shrink the heap to get it to -Xmaxf free space, without going below the initial (-Xms) value. This figure is rounded down to a 512-byte boundary on 32-bit JVMs or a 1024-byte boundary on 64-bit JVMs.
- A compaction was not done on this garbage collection cycle.
- No free chunk is at the end of the heap, or the size of the free chunk that is at the end of the heap is less than 10% of the required shrinkage amount.
- The GC did not shrink and compact on the last garbage collection cycle.
On initialization, the JVM allocates the whole heap in a single contiguous area of virtual storage. The amount that is allocated is determined by the setting of the -Xmx parameter. No virtual space from the heap is ever freed back to the native operating system. When the heap shrinks, it shrinks inside the original virtual space.
Whether any physical memory is released depends on the ability of the native operating system. If it supports paging; the ability of the native operating system to commit and decommit physical storage to the virtual storage; the GC uses this function. In this case, physical memory can be decommitted on a heap shrinkage.
You never see the amount of virtual storage that is used by the JVM decrease. You might see physical memory free size increase after a heap shrinkage. The native operating system determines what it does with decommitted pages.
Where paging is supported, the GC allocates physical memory to the initial heap to the amount that is specified by the -Xms parameter. Additional memory is committed as the heap grows.
For more information, refer to Heap shrinkage.