Garbage Cleanup of JVM using SERVICE_RECLAIM command
|Date:||10 October 2014|
|Product/Release:||LANSA Integrator - All Versions|
|Abstract:||Garbage Cleanup of JVM using SERVICE_RECLAIM command|
|Submitted By:||LANSA Technical Support|
Built-in into the latest JSM is the SERVICE_RECLAIM command.
This command can be called on any loaded service. This command calls the System.gc () method to run a 'forced/explicit' Garbage Collection (GC) Cycle.
You can also enable Heap compaction on a this type of explicit GC call.
To trace this event, simply add the compaction keyword to the trace GC option.
A possible usage scenario.
At the end of a batch run of JSM service processing, you can call SERVICE_RECLAIM to explicitly run the Garbage Collector and compact the heap.
This will return your JSM heap to the minimum number of live objects and the heap will be compacted.
This heap compaction might also cause a heap shrinkage.
Therefore heap will have a large contiguous block of memory to allocate new objects and will be ready for the next batch run of JSM services.
For more information refer to Java Diagnostics Guide - Heap expansion and Heap shrinkage.
The following are some key points to take note of :
- Heap shrinkage occurs after garbage collection while exclusive access of the virtual machine is still held.
- 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 or not any physical memory is released depends on the ability of the native operating system.
- You never see and decrease in the amount of virtual storage that is used by the JVM.
- 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.
USE BUILTIN(JSM_OPEN) WITH_ARGS('LOCALHOST:7560') TO_GET(#JSMSTS #JSMMSG)
USE BUILTIN(JSM_COMMAND) WITH_ARGS('SERVICE_LOAD SERVICE(XXXService)') TO_GET(#JSMSTS #JSMMSG)
USE BUILTIN(JSM_COMMAND) WITH_ARGS(SERVICE_RECLAIM) TO_GET(#JSMSTS #JSMMSG)
USE BUILTIN(JSM_CLOSE) TO_GET(#JSMSTS #JSMMSG)
JSM job spooled file output
-Xmca32K RAM class segment increment
-Xmco128K ROM class segment increment
-Xmns10000K initial new space size
-Xmnx512M maximum new space size
-Xms40000K initial memory size
-Xmos30000K initial old space size
-Xmox2G maximum old space size
-Xmx2G memory maximum
-Xmr16K remembered set size
-Xlp64K large page size
available large page sizes: 4K 64K
-Xmso256K operating system thread stack size
-Xiss2K java thread stack initial size
-Xssi16K java thread stack increment
-Xss256K java thread stack maximum size
excessiveGC: gcid="1" intimems="4.100" outtimems="815.502" percent="0.50" averagepercent="0.03"
excessiveGC: gcid="2" intimems="8.253" outtimems="940.371" percent="0.87" averagepercent="0.07"
excessiveGC: gcid="3" intimems="12.067" outtimems="1182.194" percent="1.01" averagepercent="0.11"
Compact(1): reason = 4 (forced gc with compaction)
Compact(1): Thread 0, setup stage: 0 ms
Compact(1): Thread 0, move stage: handled 71336 objects in 6 ms, bytes moved 3658472.
Compact(1): Thread 0, fixup stage: handled 0 objects in 0 ms, root fixup time 0 ms.
Compact(1): Thread 1, setup stage: 0 ms.