Bug in 12.0.0 loading huge 19G heap dump?

[work.asr]

No matter how much memory I have, the load dies at around 93%. Here is the log from the last time I tried it, starting Yourkit with a 96G heap!
It ends with exception caught at ObjectStorageNatives.cpp:369

Code: Select all

12.0.0 - 2.468: Command line:
  /usr/jdk/jdk1.6.0_35/bin/amd64/java
  -Xms96g
  -Xmx96g
  -XX:PermSize=256m
  -XX:MaxPermSize=256m
  -XX:+HeapDumpOnOutOfMemoryError
  -Xbootclasspath/a:/usr/jdk/jdk1.6.0_35/lib/tools.jar
  -jar
  ./../lib/yjp.jar
12.0.0 - 2.468: uname:
  sysname: SunOS
  release: 5.10
  version: Generic_147441-12
  machine: i86pc
12.0.0 - 2.468: Solaris; 64-bit process
12.0.0 - 2.468: shmem 4234148E: OK
12.0.0 - 2.481: shmem 42341490: OK
12.0.0 - 192.211: Loader for HPROF: /data/smart.heap.bin
12.0.0 - 192.249: pass1: starting
12.0.0 - 462.504: pass1: finished
12.0.0 - 462.516: pass2: starting
12.0.0 - 658.834: pass2: finished
12.0.0 - 712.112: OIDs converted
12.0.0 - 712.116: createStorage: objectCount=342379476: process: CPU 470007 ms (kernel: 67643 ms)
12.0.0 - 727.472: createStorage: result=28785520: process: CPU 485610 ms (kernel: 78165 ms)
12.0.0 - 728.776: pass3: starting
12.0.0 - 1273.933: pass3: finished
12.0.0 - 1336.259: initMemPart: 0
12.0.0 - 1336.764: initMemPart: 1
12.0.0 - 1583.533: initMemPart: 2
12.0.0 - 1583.534: initMemPart: 3
12.0.0 - 1678.690: initMemPart: 4
12.0.0 - 1678.693: dc: 0: process: CPU 1470256 ms (kernel: 133393 ms)
12.0.0 - 1678.695: dc: 1: oc=342379477 rc=3536: process: CPU 1470257 ms (kernel: 133393 ms)
12.0.0 - 1678.701: exception caught at ObjectStorageNatives.cpp:369

[work.asr]

Further information. I ran a truss (system trace) and this is what happened right after "12.0.0 - 1678.690: initMemPart: 4"

Code: Select all

19950/45:   write(20, " 1 2 . 0 . 0   -   1 6 7".., 34) = 34
19950/21:   mprotect(0xFFFFFD7FFDD90000, 4096, PROT_READ)   = 0
19950/45:       Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFD7FFAC10F02
19950/45:         siginfo: SIGSEGV SEGV_ACCERR addr=0xFFFFFD7FFDD90100
19950/21:   mprotect(0xFFFFFD7FFDD90000, 4096, PROT_READ|PROT_WRITE) = 0
19950/45:       Received signal #11, SIGSEGV [caught]
19950/45:         siginfo: SIGSEGV SEGV_ACCERR addr=0xFFFFFD7FFDD90100
19950/21:   mprotect(0xFFFFFD7FFDF30000, 4096, PROT_NONE)   = 0
19950/45:   lwp_sigmask(SIG_SETMASK, 0xFFBFFEFF, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF]
19950/45:   setcontext(0xFFFFFD7FE3FFDAC0)
19950/21:   mprotect(0xFFFFFD7FFDF30000, 4096, PROT_READ)   = 0
19950/21:   lwp_cond_signal(0x01B7C248)         = 0
19950/21:       condvar type: USYNC_THREAD
19950/45:   lwp_cond_wait(0x01B7C248, 0x01B7C230, 0x00000000, 0) = 0
19950/45:       condvar type: USYNC_THREAD
19950/45:       mutex type: USYNC_THREAD

[Anton Katilin]

Please don't set such big -Xmx unless you get an error message which explicitly tells to do so.

Instead, set something like -Xm4G or 8G. That most likely will be enough.

The reason is that the biggest part of the snapshot is directly mapped to memory outside the Java help.

[Anton Katilin]

Another hint:

The error happens during the most memory hungry operation - the dominator tree calculation. As a workaround you can skip it by adding the following line to the file <profiler installation directory>/bin/yjp.ini:
-Dyjp.dominators=false

This should allow the snapshot to load, but retained sizes will not be immediately shown for individual objects in object explorers; instead, retained size will be shown equal to the shallow size. Also, the Biggest objects/dominator tree view will be incorrect - it will also be build on shallow sizes. But it's not a big problem: you can explicitly calculate retained size for a selected item by using Quick info (Ctrl+Q). Class list will show retained sizes after applying Calculate exact retained sizes.

[work.asr]

I tried 8g heap and it died the same way. (Error box says "Not enough virtual memory" btw).
I tried 4g heap and it dies with java.lang.OutOfMemoryError: Java heap space.

I will try your -Dyjp.dominators=false suggestion with 8g heap next (also downloaded 12.0.1).

[work.asr]

-Dyjp.dominators=false with 8g heap did the trick. Thank you!!

[work.asr]

One thing is making it very difficult to use the tool with the -Dyjp.dominators=false setting.
I am tracking down instances to see where our memory is being used and I do a quick info to get the real retained size on various elements but the table doesn't update with this real value.
Any ideas on how to work around this?

[Anton Katilin]

Which table do you mean? If it's the Class list view or another view having "Calculate exact retained sizes" control - use it. Otherwise you can't have the exact sizes without using Quick info.

Note: -Dyjp.dominators=false is not a normal mode of operation. It's just a workaround to enable loading of huge snapshots on machines with lack of memory.

So I can only suggest to find a 64-bit machine with more memory available and try opening the snapshot on it.

[Anton Katilin]

FYI: we've improved snapshot loading in v2014 EAP:
http://www.yourkit.com/eap

If you still have that or similar huge snapshots, please try opening them with the new build.