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 vv159170. It already has 1 duplicates Build: NetBeans IDE Dev (Build 20130128-1d53acd6cd83) VM: Java HotSpot(TM) 64-Bit Server VM, 20.10-b01, Java(TM) SE Runtime Environment, 1.6.0_35-b10 OS: Linux User Comments: vv159170: clicking in navigator Maximum slowness yet reported was 3701 ms, average is 3701
Created attachment 130762 [details] nps snapshot
see also bug 189036, I saw the same blocked AbstractLookup.enterStorage() there
The fact that the monitor is static, is not important (the code is not waiting to enter shared monitor, but in Object.wait) the behavior would be the same even if the lock was per lookup instance. It seems that the problem is proliferation of AbstractLookup.Result instances. With every click in CND qnavigator new instances of Result are generated (for each queried class). There can be thousands of such instances. When GCed, they then hold the lock for a significant amount of time. I am changing the known lookups to return existing instances, if possible.
ergonomics#ab41f4584b22
thanks, Jarda!
Integrated into 'main-golden', will be available in build *201302010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ab41f4584b22 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #225449: Lookup queries are blocked due to wait on monitor while doing cleanup AbstractLookup and ExcludingLookup modified to keep track of existing Results and search them before creating a new one. This increased size of ExcludingLookup by 8 bytes and assertSize as some assertGC tests needed to be modified.
verified
Looks like fix has serious side effect causing OOM. Although Lookup.Results are not generated all the time now, but listeners are added to found previous result instance unconditionally in AbstractKookup.modifyListenerList => AbstractLookup.listeners field grows up (I see at least 240'000 in hprof) in several instances. I found reproducible scenario: - open new c++ file and change selection in navigator => ~ +200 listeners are added and not removed. - close file and open new one, ... continue to do the same Our automatic tests checks big projects => get OOM. Looks like listener shouldn't be added if it (or equal one) is already in listeners list
I can provide hprof, if you need it
deferring to NB 7.3 patch 2
temporary backout to prevent OOM: http://hg.netbeans.org/cnd-main/rev/733514b66c94
Integrated into 'main-golden', will be available in build *201303112300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/733514b66c94 User: Egor Ushakov <gorrus@netbeans.org> Log: Backout of the fix for #225449, revision ab41f4584b22
*** Bug 227227 has been marked as a duplicate of this bug. ***
The problems always happen only with CND navigator component. Can you verify NavigatorComponent.getLookup() implementation and confirm it does not create new lookup instances needlessly? I am going to reintegrate my fix.
changeset: d46128064b43 tag: tip user: Jaroslav Tulach <jtulach@netbeans.org> date: Wed Mar 27 15:18:46 2013 +0100 summary: Re-integrating #225449. The broken behaviour (which initiated the rollback) was due to cnd.qnavigator misbehavior.
Jarda, thanks for the fix for cnd.qnavigator. Btw, at night we've got OOM (navigator was not fixed yet) => don't you think it's worth to fix listeners part anyway?
I know this fix in lookup caused a memory leak in editor. Mílo, can your crosslink your issue?
Removing 73patch2-candidate as the fix is not quite safe. It is much safer to backport cnd.qnavigator fix.
It was issue #228361. Only weak listeners should be attached to Lookup.Result. Reference to L.R typically needs to be held as a field in an object instance to prevent the L.R from being GCed. Let's call the object Cls1. Cls1 instance may be statically reachable e.g. a part of some global cache. So far so good. L.R instance is then also statically reachable. Now let's assume another class Cls2. If that one would attach a regular non-weak listener on (shared) L.R then Cls2 object instance becomes statically reachable.