Skip to main content

Cannot load heap dump with jhat

13 replies [Last post]
sv
Offline
Joined: 2003-06-13

jhat -J-Xmx1300m heap.dump(and i cannot specify more than 1300m) raise an error(dump wath created with jse beta):

#
# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 167772160 bytes for GrET in C:\BUILD_ARE
A\jdk6\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
#
# Internal Error (414C4C4F434154494F4E0E494E4C494E450E4850500017), pid=177276,
tid=178280
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-b74 mixed mode)
# An error report file with more information is saved as hs_err_pid177276.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

what i do wrong?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24

Let's just say that I'm not a big fan of JHAT's memory consumption. I tried using it for weeks to try to debug some memory leaks in Netbeans and for weeks I kept on running into the same thing: JHAT would require 4x more memory to run than the size of the heap dump. I couldn't even get a 256MB heap dump to load sometimes (1.3GB was not enough).

Memory usage has been improved so now I can load a 256MB dump but 512MB is still out of bounds.

I don't forsee myself having access to a 64-bit machine anytime soon and I think it is fair to say the same for most users out there. Is there anything we can do for JHAT to further tweak memory usage? Or, better yet, can we somehow get the 32-bit JVM to run beyond the 1.3GB limit?

Gili

antonkatilin
Offline
Joined: 2006-03-23

Hello,

We have supported HPROF binary format snapshots in our profiler UI. The UI can handle huge snapshots as well as provides cool analysing capabilities. You can get it at http://www.yourkit.com/eap

Best regards,
Anton

cowwoc
Offline
Joined: 2003-08-24

Anton,

Approximately how much memory does it use to open up a typical 256MB heap dump?

Gili

peterkessler
Offline
Joined: 2004-10-27

Would you please try running with the [code]-XX:-UseBiasedLocking[/code] flag on the command line? Thanks. The implementation of biased locking up through b74 causes many more objects to have headers that need to be saved. This will be fixed in a future build.

sv
Offline
Joined: 2003-06-13

Great thanks for quick response!

Maybe i need to try b75 to take heap dumps? or use 64bit VM?
And another question: what i have to do when i want to view dumps 2-3 times more in size(curently 438 MB)?
I run jhat with different flags,output below
----------------------------------------------------------------------
jhat.exe -J-XX:-UseBiasedLocking -J-server -J-Xmx1300m heap.dump
Reading from heap.dump...
Dump file created Tue Mar 07 14:26:53 MSK 2006
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceede
d
at com.sun.tools.hat.internal.parser.HprofReader.readInstance(HprofReade
r.java:748)
at com.sun.tools.hat.internal.parser.HprofReader.readHeapDump(HprofReade
r.java:490)
at com.sun.tools.hat.internal.parser.HprofReader.read(HprofReader.java:2
23)
at com.sun.tools.hat.internal.parser.Reader.readFile(Reader.java:91)
at com.sun.tools.hat.Main.main(Main.java:143)
---------------------------------------------------------------------------
jhat.exe -J-XX:-UseBiasedLocking -J-Xmx1300m heap.dump
Reading from heap.dump...
Dump file created Tue Mar 07 14:26:53 MSK 2006
Snapshot read, resolving...
Resolving 8410895 objects...
Chasing references, expect 1682 dots............................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
....................................................Exception in thread "main" j
ava.lang.OutOfMemoryError: Java heap space
at com.sun.tools.hat.internal.model.JavaHeapObject.addReferenceFrom(Java
HeapObject.java:149)
at com.sun.tools.hat.internal.model.Snapshot$MyVisitor.visit(Snapshot.ja
va:153)
at com.sun.tools.hat.internal.model.JavaObject.visitReferencedObjects(Ja
vaObject.java:161)
at com.sun.tools.hat.internal.model.Snapshot.calculateReferencesToObject
s(Snapshot.java:242)
at com.sun.tools.hat.internal.model.Snapshot.resolve(Snapshot.java:208)
at com.sun.tools.hat.Main.main(Main.java:152)

---------------------------------------------------------------------------
And if you want i can upload dump to somewhere.

alanb
Offline
Joined: 2005-08-08

There was some work done to improve the memory requirements of jhat over the original Heap Analysis Tool (HAT). However its internal model still requires a lot of memory and there can be extreme cases that mean it needs more memory than the original heap where the dump is taken (one example is when the heap contains millions of zero length arrays). In this case you seem to need >1.3GB to read a 438MB dump which seems very excessive. The dumps are portable so if you have a 64-bit system then you should be able to analyze it.

sv
Offline
Joined: 2003-06-13

On 64-bit i able to load that dump only with folowing options:
./jdk1.6.0/bin/jhat -J-Xmx5g -J-client -J-XX:-UseBiasedLocking heap.dump
(also tried -Xmx4g -XX:-UseBiasedLocking;-Xmx3g -XX:-UseBiasedLocking;-Xmx3g; and getting OOM with it)
Thanks for help,patience :-)

sundararajana
Offline
Joined: 2004-05-26

Hi "sv": will you please give us copy of your heap dump for debugging? If possible, will you please post it in your website somewhere and let me know the link?

Thanks,
-Sundar
http://blogs.sun.com/sundararajan

sundararajana
Offline
Joined: 2004-05-26

With build 83+, there are few improvements in the way jhat handles large heap dumps. jhat still requires large -Xmx value - but the factor of -Xmx to heapdump size has been reduced. FYI.

alanb
Offline
Joined: 2005-08-08

Also, the issue with the biased locking implementation saving too many object headers was fixed in b79 - this was original "Out of swap space" issue that "sv" reported in this forum thread.

alanb
Offline
Joined: 2005-08-08

Can you post the fatal error log (hs_err_pid177276.log), or at least the THREAD section. This might be a known issue (like 6365248 for example).

sv
Offline
Joined: 2003-06-13

#
# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 167772160 bytes for GrET in C:\BUILD_AREA\jdk6\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?
#
# Internal Error (414C4C4F434154494F4E0E494E4C494E450E4850500017), pid=177276, tid=178280
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-b74 mixed mode)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

--------------- T H R E A D ---------------

Current thread (0x59feec00): VMThread [id=178280]

Stack: [0x5a010000,0x5a060000)
[error occurred during error reporting, step 110, id 0xc0000005]

VM_Operation (0x0092f610): generation collection for allocation, mode: safepoint, requested by thread 0x00036c00

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x5a00f000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=178252]
0x5a00cc00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=178368]
0x5a00b400 JavaThread "Attach Listener" daemon [_thread_blocked, id=178264]
0x5a00a800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=179888]
0x59ffe000 JavaThread "Finalizer" daemon [_thread_blocked, id=178208]
0x59ff1c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=178272]
0x00036c00 JavaThread "main" [_thread_blocked, id=178228]

Other Threads:
=>0x59feec00 VMThread [id=178280]
0x5a240800 WatcherThread [id=178944]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x000356d8/0x000006f8] Threads_lock - owner thread: 0x59feec00
[0x00035858/0x000006bc] Heap_lock - owner thread: 0x00036c00

Heap
def new generation total 92160K, used 92160K [0x029c0000, 0x08dc0000, 0x08dc0000)
eden space 81920K, 100% used [0x029c0000, 0x079c0000, 0x079c0000)
from space 10240K, 100% used [0x083c0000, 0x08dc0000, 0x08dc0000)
to space 10240K, 0% used [0x079c0000, 0x079c0000, 0x083c0000)
tenured generation total 1228800K, used 1192420K [0x08dc0000, 0x53dc0000, 0x53dc0000)
the space 1228800K, 97% used [0x08dc0000, 0x51a39208, 0x51a39400, 0x53dc0000)
compacting perm gen total 12288K, used 2537K [0x53dc0000, 0x549c0000, 0x57dc0000)
the space 12288K, 20% used [0x53dc0000, 0x5403a530, 0x5403a600, 0x549c0000)
No shared spaces configured.

Dynamic libraries:
0x00400000 - 0x0040a000 C:\Program Files\Java\jdk1.6.0\bin\jhat.exe
0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll
0x6d010000 - 0x6d01a000 C:\Program Files\Java\jdk1.6.0\bin\jli.dll
0x7c340000 - 0x7c396000 C:\Program Files\Java\jdk1.6.0\bin\MSVCR71.dll
0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll
0x5cb70000 - 0x5cb96000 C:\WINDOWS\system32\ShimEng.dll
0x6f880000 - 0x6fa4a000 C:\WINDOWS\AppPatch\AcGenral.DLL
0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll
0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll
0x774e0000 - 0x7761d000 C:\WINDOWS\system32\ole32.dll
0x77c10000 - 0x77c68000 C:\WINDOWS\system32\msvcrt.dll
0x77120000 - 0x771ac000 C:\WINDOWS\system32\OLEAUT32.dll
0x77be0000 - 0x77bf5000 C:\WINDOWS\system32\MSACM32.dll
0x77c00000 - 0x77c08000 C:\WINDOWS\system32\VERSION.dll
0x7c9c0000 - 0x7d1d5000 C:\WINDOWS\system32\SHELL32.dll
0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll
0x769c0000 - 0x76a73000 C:\WINDOWS\system32\USERENV.dll
0x5ad70000 - 0x5ada8000 C:\WINDOWS\system32\UxTheme.dll
0x773d0000 - 0x774d2000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
0x5d090000 - 0x5d127000 C:\WINDOWS\system32\comctl32.dll
0x6d790000 - 0x6d9ca000 C:\Program Files\Java\jdk1.6.0\jre\bin\client\jvm.dll
0x6d300000 - 0x6d308000 C:\Program Files\Java\jdk1.6.0\jre\bin\hpi.dll
0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL
0x6d740000 - 0x6d74c000 C:\Program Files\Java\jdk1.6.0\jre\bin\verify.dll
0x6d390000 - 0x6d3af000 C:\Program Files\Java\jdk1.6.0\jre\bin\java.dll
0x6d780000 - 0x6d78f000 C:\Program Files\Java\jdk1.6.0\jre\bin\zip.dll

VM Arguments:
jvm_args: -Dapplication.home=C:\Program Files\Java\jdk1.6.0 -Xms8m -Xmx1300m
java_command: com.sun.tools.hat.Main heap.dump
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0
PATH=D:\work\ruby\bin;C:\Program Files\Java\jdk1.6.0\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft Command Shell\v1.0\;C:\Program Files\WinSCP3\
USERNAME=sv
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 3, GenuineIntel

--------------- S Y S T E M ---------------

OS: Windows XP Build 2600 Service Pack 2

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2096620k(45272k free), swap 4036284k(1744212k free)

vm_info: Java HotSpot(TM) Client VM (1.6.0-beta2-b74) for windows-x86, built on Mar 2 2006 00:26:50 by "java_re" with unknown MS VC++:1310

alanb
Offline
Joined: 2005-08-08

A process on Windows is limited to 2GB of virtual memory (although there is a boot switch to change that). From the error log I would guess you are close to that limit when running with a 1.3GB heap and then you crash when a large (native) allocation fails during GC. 160MB does seem excessive but it may be a known/temporary issue in mustang whereby the GC is saving a lot more object headers that might be expected. As a test try running with the -XX:-UseBiasedLocking option and see if that works. If it doesn't it might mean you need to reduce the -Xmx option.