Build: NetBeans IDE 7.4 Beta (Build 201307092200)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b15
GUEST: Reverting modifications while scanning was taking place
powellblyth: Accidentally Cmd+A on the file tree, Didn't know it would do that. Does it need to?
GUEST: selecting 200+ file in favorites window.
jmichelberger: Selecting multiple nodes in Files view.
Maximum slowness yet reported was 24439 ms, average is 7049
Created attachment 139882 [details]
steps to reproduce:
1) open favorites and expand a folder with lots of files
2) wait until all nodes are loaded (all icons are correctly displayed)
3) Ctrl + A
From what we got while debugging:
- lookup is being built for all the nodes ProxyLookup$Result#1
- first node (when building its lookup) fires an event (for some reason its cookie set changes)
- the ProxyLookup$Result#1 catches the event and before passing it further it starts collecting all changes from all nodes again
- so it asks the second node which now fires another event => ProxyLookup$Result#1 again catches the event and recursively asks node after node again and again.
See the attached partial stacktrace, ProxyLookup$R is always the same instance, DataNode/DataObject instances are different in the stacktrace. Maybe ProxyLookup could be more clever and stop reacting on changes and recursively accessing all nodes when it's building?
Created attachment 143305 [details]
Created attachment 143306 [details]
Jardo, your patch helped after all and made it much much faster.
ergonomics#f143d26b5461 seems speed the selection up significantly. Hopefully it won't cause many test regressions and I will be able to propagate it to 8.0.
*** Bug 240901 has been marked as a duplicate of this bug. ***
Integrated into 'main-silver', will be available in build *201402170649* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #235748: Limit the recursion from updateCookiesFromLookup
*** Bug 241548 has been marked as a duplicate of this bug. ***
*** Bug 204645 has been marked as a duplicate of this bug. ***
I am still seeing this issue in Release 8.0.1;
Created attachment 150582 [details]
stack traces showing the issue in Netbeans 801 release, at multiple points
Issue still exists.
What do you mean by "the issue"? Please be more specific. What happened to you and how that manifested? What you were doing?
I see only one report from 8.0.1 in the exception reporter:
but that report is about "OutOfMemoryError: Java heap space" which is something completely different than the original report in this issue!
The thread dump in the issue shows your IDE is parsing/checking the disk. That is however not a reason to throw OOME.
There is 7M of TreeMap.Entry instances occupying 412MB of memory. It could be related to javax.management.openmbean.CompositeDataSupport which has 1.4M of instances. Possibly the slowness detector profiler has problems with deep stack traces that happen when StackOverFlowError is raised. And yes, there is one in messages.log:
Anyway your problem does not seem to have anything to do with lookup. Closing this bug and reporting as bug 249103