This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
On a big heap dump (>500Mb) I selected an instance and asked for the nearest GC roots. Since after a while it was still only at 1%, I closed the dialog box with progress, thinking this would cancel the computation. But it did not, as I saw in a thread dump half an hour later: "NBSwingWorker - RequestProcessor" daemon prio=10 tid=0xaeb9b000 nid=0x49a8 runnable [0xaccf4000] java.lang.Thread.State: RUNNABLE at java.util.ArrayList.size(ArrayList.java:177) at java.util.AbstractList$Itr.hasNext(AbstractList.java:339) at org.netbeans.lib.profiler.heap.NearestGCRoot.computeOneLevel(NearestGCRoot.java:182) at org.netbeans.lib.profiler.heap.NearestGCRoot.computeGCRoots(NearestGCRoot.java:126) - locked <0x76f38598> (a org.netbeans.lib.profiler.heap.NearestGCRoot) at org.netbeans.lib.profiler.heap.NearestGCRoot.getNearestGCRootPointer(NearestGCRoot.java:95) at org.netbeans.lib.profiler.heap.InstanceDump.getNearestGCRootPointer(InstanceDump.java:105) at org.netbeans.modules.profiler.heapwalk.model.BrowserUtils.computeChildrenToNearestGCRoot(BrowserUtils.java:166) at org.netbeans.modules.profiler.heapwalk.ReferencesBrowserController$2.doInBackground(ReferencesBrowserController.java:226) at org.netbeans.lib.profiler.ui.SwingWorker$2.run(SwingWorker.java:113) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1415) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1954) I had to shut down the IDE to stop it.
It will be hard to cancel the task. BTW: The GC root computation time is more related to number of objects in the heap dump rather than its size. Which JDK version did you use to open the heap dump? Did you use 32bit or 64bit JVM?
(In reply to comment #1) > It will be hard to cancel the task. You might try Thread.interrupted, say from HeapProgress.progress. BTW you can now use standard javax.swing.SwingWorker. > The GC root computation time is more > related to number of objects in the heap dump rather than its size. Understood, but it had a lot of objects too. I didn't seriously expect it to be fast to compute, but I thought it might finish in a few minutes, like opening the dump or listing direct references to a sample instance did; whereas it began to look like calculating GC root refs would take more like an hour if the progress bar was to be trusted. (If you can find a way to speed up this calculation it would be very valuable, since when I open a heap dump this is most often what I am interested in seeing.) > Which JDK version did you use to open the heap dump? 6u20, 32-bit (Linux).
(In reply to comment #2) > (In reply to comment #1) > > It will be hard to cancel the task. > > You might try Thread.interrupted, say from HeapProgress.progress. This is the easiest part. The hard part is to cancel the computation in such a way that the heap model remains in the consistent state and computation of the GC roots can be restarted. > (If you can find a way to speed up this calculation it would be very valuable, > since when I open a heap dump this is most often what I am interested in > seeing.) I did some improvements in #186031. > > Which JDK version did you use to open the heap dump? > > 6u20, 32-bit (Linux). Java on Linux is know to have slow implementation of memory mapped files. Can you try 64bit JDK? It should help. It would be good to have your heap dump for testing purposes. Do you till have it?
(In reply to comment #3) > Java on Linux is know to have slow implementation of memory mapped files. Can > you try 64bit JDK? It should help. No, I am running a 32-bit kernel. > It would be good to have your heap dump for testing purposes. Do you still have > it? Sorry, no.
(In reply to comment #4) > > It would be good to have your heap dump for testing purposes. Do you still have > > it? > > Sorry, no. Ok, if you encounter it again, please save such heapdump. I would like to check that the computation does not take too much time. 30 minutes looks too long to me. I would also like to run it on different operating systems to see if there are any differences in computation time.
*** Bug 190067 has been marked as a duplicate of this bug. ***
*** Bug 225878 has been marked as a duplicate of this bug. ***