How long to run compute retained sizes in visual VM for a 1GB heap?

Question

I have a 1 GB heap dump from a java process that ran out of heap space. I have uploaded the heap into jvisualm that comes with a java6 distribution. I started the "compute retained sizes" process around 16 hours ago and it is still running. How long should it take to run the compute retained sizes for the top 20 objects on a 1GB heap? Should I expect it to ever finish?

Cherubini

I have no idea of what you're talking about(I have little experience with Java), but my logic tells me that if you're not running this on 1 GHz with 1 GB RAM(or less) system, 16 hours is waaay too much... – Cutworm

Just for curiosity, did it finish? How long did it take? If it did not finish, did a 2nd run finished successfully? – Coan

It never did finish. I ended up downloading a YourKit trial and it finished the same process in around 20 minutes. – Cherubini

Just for the record: a 14GB heap dump (.bin) took about 12h on a MacBook Pro 16GB RAM. VisualVM was given 10G with -J-Xmx10g. – Picador

Answer 1

It seems to take forever on my machine as well, but I noticed from the taskmanager that nothing seemed to happen anymore (low CPU uage, Disk I/O). The reason was that although the progress indicator keeps showing an animation the action was silently aborted according to the log file.

To open the log I used these steps:

• Click Help
• Click About
• Click Logfile

This showed me at the bottom of the log:

SEVERE [org.openide.util.RequestProcessor]
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.HashMap.newNode(HashMap.java:1734)
    at java.util.HashMap.putVal(HashMap.java:630)
    at java.util.HashMap.put(HashMap.java:611)
    at java.util.HashSet.add(HashSet.java:219)
    at org.netbeans.lib.profiler.heap.DominatorTree.intersect(DominatorTree.java:279)
    at org.netbeans.lib.profiler.heap.DominatorTree.computeOneLevel(DominatorTree.java:114)
    at org.netbeans.lib.profiler.heap.DominatorTree.computeDominators(DominatorTree.java:64)
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSize(HprofHeap.java:537)
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSizeByClass(HprofHeap.java:594)
    at org.netbeans.lib.profiler.heap.ClassDump.getRetainedSizeByClass(ClassDump.java:102)
    at org.netbeans.modules.profiler.heapwalk.HeapFragmentWalker.computeRetainedSizes(HeapFragmentWalker.java:100)
    at org.netbeans.modules.profiler.heapwalk.ClassPresenterPanel$1$1.run(ClassPresenterPanel.java:187)
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1393)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2003)

By default my 64 bit Java VM Heapsize will be limited to 25% of my computer memory (or even a much lower VisualVM builtin limit). To solve this issue for my next attempt I wil try again starting VisualVM like this:

jvisualvm.exe -J-Xmx16g

After this the log shows at startup:

Heap memory usage: initial 24,0MB maximum 14563,6MB

Outshout

I found that jvisualvm was ignoring the mx command line flag from the command line, since it was already pulling in a default value of -Xmx256m from %JDK_HOME%\lib\visualvm\etc\visualvm.conf. See #9571421 – Phosphorate

Answer 2

I had a 600MB heap that just took 900 CPU-minutes of time to compute retained sizes. That's 15 hours. I would assume it's very related to what's on the heap, so I won't extrapolate to your heap (also you pointed out it didn't finish ;), but it's another data point.

Joashus