When you debug Java heap fragmentation or memory problems, it can be helpful to find the stack traces of the thread that makes large allocation requests.
Set generic JVM argument: -Xdump:stack:events=allocation,filter
If you are using WebSphere Application Server Version 8 or later and capture javacores close to the time of the large memory requests, then there may not be a need to set any command line parameters at all. In the verbose GC output look for a large value in the "minimum requested bytes" field. "minimum requested bytes" tells the size of the allocation request (as large or as small as it may be) and the following "lastthreadtid" is the ID of the thread that made the request. Match the "lastthreadtid" in the verbosegc log to the "J9VMThread" in the related javacore to determine the code which was running at the time of the memory request.
<af type="nursery" id="1" timestamp="Jul 19 22:04:47 2013" intervalms="0.000">
<minimum requested_bytes="5256" />
<time exclusiveaccessms="0.062" meanexclusiveaccessms="0.062" threads="0" lastthreadtid="0x0000000002C2EC00" />
Match the "lastthreadtid" to the javacore "J9VMThread" thread stack:
"threadx-1x" J9VMThread:0x0000000002C2EC00, j9thread_t:0x00007F3E042768D0, java/lang/Thread:0x00000000273C4E10, state:CW, prio=5
(native thread ID:0x4E35, native priority:0x5, native policy:UNKNOWN)
(native stack address range from:0x00007F3DFF567000,
at java/net/SocketInputStream.socketRead0(Native Method)
NOTE: The javacore may not have been captured at the precise time the large request was made and therefore may not be a representation of what code made the allocation request. Typically a thread makes repeated types of requests and it is likely you can catch the culprit in this manner.
Else, -Xdump:stack:events=allocation,filter works as in previous versions:
Starting with WebSphere Application Server version 6.1 with IBM SDK SR10 and later and WebSphere Application Server version 7 with IBM SDK 1.6 with SDK SR5 and later, use
If you set this option to a value nnn (bytes), whenever an allocation request is made for an object size >= nnn (bytes), the Java stack trace corresponding to the thread requesting the allocation is printed into the standard error log.
There are instances when this option will not print the Java stack. It will not print Java stack when JVM considers printing of the Java stack as an unsafe operation and so the Java stack will not be printed for some threads. It is considered to be an limitation of this environment variable.
**Note: -Xdump will incur some performance overhead directly proportional to the value the filter/threshold is set.
For details on where to set the -Xdump argument:
"Setting generic JVM arguments in WebSphere Application Server"
For more information on the -Xdump argument:
"MustGather: Using the -Xdump Option"
To use the -Xdump option can be set to trigger a dump of the stack that makes an allocation request above or within a certain size range.
On the command line or in the generic JVM arguments set:
This will print the stack information for all allocations over 10m to the native_stderr.log
|Or view an allocation within a certain range of values:
This will print the stack information for all allocations between 2m and 4m to the native_stderr.log
|In the native_stderr log locate the output by searching for
|"JVMDUMP006I Processing dump event "allocation""|
./java "-Xdump:stack:events=allocation,filter=#1k" -version
JVMDUMP006I Processing dump event "allocation", detail "1264 bytes, class [B" - please wait.
Thread=main (088B9C4C) Status=Running
at java/lang/System.getPropertyList()[Ljava/lang/String; (Native Method)
at java/lang/System.ensureProperties()V (System.java:254)
at java/lang/System.<clinit>()V (System.java:101)
at java/lang/J9VMInternals.initializeImpl(Ljava/lang/Class;)V (Native Method)
at java/lang/J9VMInternals.initialize(Ljava/lang/Class;)V (J9VMInternals.java:200)
at java/lang/ClassLoader.initializeClassLoaders()V (ClassLoader.java:72)
at java/lang/Thread.initialize(ZLjava/lang/ThreadGroup;Ljava/lang/Thread;)V (Thread.java:325)
at java/lang/Thread.<init>(Ljava/lang/String;Ljava/lang/Object;IZ)V (Thread.java:124)
|Application Servers||Runtimes for Java Technology||Java SDK|