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.

Xcompactexplicitgc

To trace this event, simply add the compaction keyword to the trace GC option.

-Xtgc:excessiveGC,compaction

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)

SystemDefault.properties

    #AllowOptions
    -verbose:sizes
    -Xgcpolicy:gencon
    -Xcompactexplicitgc
    -Xtgc:excessiveGC,compaction
    -Xverbosegclog:GC-%Y-%m-%d-%H%M%S.XML

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.