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
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?
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