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.
This issue was reported manually by jglick. It already has 1 duplicates Build: NetBeans IDE Dev (Build 20150330-a97a99638a8e) VM: Java HotSpot(TM) 64-Bit Server VM, 25.25-b02, Java(TM) SE Runtime Environment, 1.8.0_25-b17 OS: Linux User Comments: jglick: Tried Find in Forward Calls. IDE hung for maybe a minute, then recovered and show me the forward calls. On another hotspot, tried Find in Reverse Calls. This time it hung and did not recover until I used my jkillthread utility to blow away the AWT EQ thread. Maximum slowness yet reported was 208929 ms, average is 208929
Created attachment 153002 [details] nps snapshot
Originally miscategorized under #227232, which seems to be where slowness reports go to die. This one is clearly a bug in the Profiler: doing potentially complex calculations in the event handler.
http://statistics.netbeans.org/analytics/exception.do?id=773314 also.
Optimized the search algorithm, works much better now. Would appreciate if you can verify it. Fixed by http://hg.netbeans.org/profiler-main/rev/a5d8011625bf.
Integrated into 'main-silver', will be available in build *201504201004* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/a5d8011625bf User: Jiri Sedlacek <jis@netbeans.org> Log: Bugfix #251598 & #250689 - use deepHashCode for TreePath.hashCode when filtering and/or sorting models
I just ran into this problem in NetBeans 8.1 trying to use Find in Reverse Calls from the Hotspot view. It seems that at least some complex calculations are still being done in the event handler? After several minutes of the UI hanging, it eventually died with an OOM error.
Based on the information provided by mintern it looks more like a memory/GC problem than complex calculation. The problem with searching results is that the search algorithm has to traverse the whole call trees to find the first/next/previous occurrence of the searched string. This is a memory-intensive operation which can eventually cause an OOME in case there's not enough heap space. Before the OOME is thrown the garbage collector does its best to prevent it, eventually blocking the EDT for a long period of time before the crash. This can be easily verified using the VisualVM which will show a significant GC overhead in the Monitor tab. The solution to speed up searching large results and prevent the OOME is to increase the heap memory for the IDE using the -Xmx parameter.
But should that potentially-long search be performed in the event handler? There were several minutes before OOM was hit, and during that time, NetBeans was completely unresponsive.
Also, for some context, I appear to be using Xmx1024m with NetBeans. How high should it be?
It's not the search operation which takes that amount of time. If there was enough heap, it would be completed within a second or so. It's the garbage collector causing the actual slowdown - note that it stops the whole JVM, not just the EDT. I can't suggest the optimal heap size as it heavily depends on the amount of collected data and depth of the profiled call trees. Just increase it for example to 1536M and try again.