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.
Build: NetBeans IDE 8.0.2 (Build 201411181905) VM: Java HotSpot(TM) 64-Bit Server VM, 25.25-b02, Java(TM) SE Runtime Environment, 1.8.0_25-b17 OS: Mac OS X User Comments: andreas_50931: I was (or tried at least to work) working normaly. Sorry to say that but actual version of NetBeans really runs poorly on my MacBook. You do not seem to focus on stable Tomcat integration any more? Nevertheless kind regards Andreas GUEST: Searching GUEST: IDE hung up as I was about to edit my templates from the file search. Stacktrace: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3181) at java.util.ArrayList.grow(ArrayList.java:261) at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235) at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227) at java.util.ArrayList.add(ArrayList.java:458) at org.openide.util.lookup.AbstractLookup.notifyListeners(AbstractLookup.java:568)
Created attachment 151933 [details] stacktrace
Almost same here. I delete several files from the file search results when Netbeans hung up. The files reappeared after reopening. The bug can be reproduced.
org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:169) it collects events + listeners (collectFires) and stores them in an arraylist -> the list contains over 70 mil. items ;-( Sorry jardo, i'm reassigning to you. Let's look at this together. This is very likely causing bug #246421 - it's a slowness caused by iterating over the items of the collected events+listeners - and because that array contains millions of listeners the slowness is imminent.
ufff, there are over 90 000 instances of org.netbeans.modules.project.ui.actions.FileAction$1($2), lot of them (if not all) being part of the mentioned lookup listeners.
seems to happen only on Mac - both this and bug 246421
Further peace of evaluation: the list in ProxyLookups.setLookups contains duplicate items: i can see e.g. two pairs: [LookupEvent(#599) -> SimpleProxyLookup$ProxyResult(#7), $Proxy7(#1266) -> WeakListImpl$ProxyListener(#32761) [LookupEvent(#718) -> SimpleProxyLookup$ProxyResult(#7), $Proxy7(#1266) -> WeakListImpl$ProxyListener(#32761) i expect a lot of other duplicate instances of the same event+listener
Synchronization in ProxyLookup$R.removeLookupListener(), which may be related to this bug, fixed in http://hg.netbeans.org/core-main/rev/8913c52bc2fc.
Another cause of the problem can be high number of lookup listeners attached to lookup results. In the heap dump, the biggest instance of LookupListener[] contains several thousand items. The listeners are of type SimpleProxyLookup$WeakResult, and the array belongs to an instance of type ProxyLookup$R. Some extra listeners might be added (due to race condition) at SimpleProxyLookup.ProxyResult.updateLookup, line 226, just after the for-loop. Reassigning. Thank you, Jarda.
Tomas Hurka observed that some snapshots from bug 246421 show that thread MainWndMac intensively retrieves items from SimpleProxyLookup$ProxyResult (e.g. snapshot 778046). Keeping only one task with this operation scheduled could help. http://hg.netbeans.org/core-main/rev/f4edb7b0adfe
I did bunch of changes to make the behavior more robust. Parent of five of them is http://hg.netbeans.org/ergonomics/rev/ff58c5c460a6 There were plenty of synchronization bugs which I demonstrated by encapsulating access to mutable fields into getters and setters and guarded it by Thread.holdsLock. I have not managed to demonstrate a case where two listeners (WeakResult) are added to the same result, but I created a test case showing that it is quite common to create and add many WeakResult instances needlessly. I fixed that. Now waiting for ergonomics build to report failures. It remains to be seen whether the changes in SimpleProxyLookup affect the global problem or not - but that is more work than I can dedicate on a weekend. Passing back to Jarda Havlín.
ergonomics build succeeded. My change is in main-silver: http://hg.netbeans.org/main-silver/rev/ff58c5c460a6
(In reply to Ondrej Vrabec from comment #4) > ufff, there are over 90 000 instances of > org.netbeans.modules.project.ui.actions.FileAction$1($2), > lot of them (if not all) being part of the mentioned lookup listeners. http://hg.netbeans.org/core-main/rev/13fa7add8dd2 Code simplified (less new objects created during refresh), using sliding task to schedule the refresh operation.
(In reply to Jaroslav Tulach from comment #11) > ergonomics build succeeded. My change is in main-silver: > http://hg.netbeans.org/main-silver/rev/ff58c5c460a6 Thank you very much. (In reply to Jaroslav Tulach from comment #10) > It remains to be seen whether the changes in SimpleProxyLookup affect the > global problem or not. I'm not sure how to verify this. We have fixed several suspicious places, so I think we can close the issue and wait. If new reports come from future builds, we'll reopen this bug.
Integrated into 'main-silver', will be available in build *201507220303* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/330a6563f0ca User: Jaroslav Tulach <jtulach@netbeans.org> Log: #250349: Guarding thread-safe access to lastListener
Integrated into 'main-silver', will be available in build *201507230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/13fa7add8dd2 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #250349: Many FileAction$1 instances in a RequestProcessor