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.
ElementImpl uses ActiveQueue for some cleanup work. The problem is that during that cleanup it needs to lock MDR and thus waits for ongoing MDR transaction. During that time, anz other cleanup work using Active queue is blocked, which can mean accumulating garbage further and further. This seems to be a problem e.g. during find usages, as the search runs under the MDR mutex, so the garbage generated during the search can§t be cleaned. Part of the thread dump: "Active Reference Queue Daemon" daemon prio=1 java.lang.Object.wait(Native Method) -waiting_on_<0x4595d3c8>(org.netbeans.modules.javacore.ExclusiveMutex) java.lang.Object.wait(Object.java:429) org.netbeans.modules.javacore.ExclusiveMutex.enter(ExclusiveMutex.java:106) -locked_<0x4595d3c8>(org.netbeans.modules.javacore.ExclusiveMutex) org.netbeans.mdr.NBMDRepositoryImpl.beginTrans(NBMDRepositoryImpl.java:232) org.netbeans.modules.java.bridge.ElementImpl$ElementListener.doRemove(ElementImpl.java:1236) org.netbeans.modules.java.bridge.ElementImpl$LWeakReference.run(ElementImpl.java:1306) org.openide.util.Utilities$ActiveQueue.run(Utilities.java:2396) java.lang.Thread.run(Thread.java:534)
old target milestone, please re-evaluate
What about post MDR stuff as a task to RequestProcessor. Would that help?
Good idea, it should work. Fixed. /cvs/java/src/org/netbeans/modules/java/bridge/ElementImpl.java,v <-- ElementImpl.java new revision: 1.26; previous revision: 1.25
Sorry I haven't jumped it later but I can't agree with the solution as it is implemented. Your fix will in the common case of several freed ElementImpl instances, just jam the default request processor as it would consume (and block) one thread for each freed ElementImpl instance. Please reuse one of java module's RPs or create your own RP for this purpose. Even better would be to use completly different mechanism, where such MDR cleanup won't depend on GC (if I understand it correctly).
OK, now, a new RP is created to handle tasks performing MDR cleanup. As for the completely different mechanism, I agree that it would be better, but I have no idea how to do it - we need to remove mdr listeners registered by src hierarchy impl elements when the elements are GCed and I am not sure if there is another possibility to be notified about this state. /cvs/java/src/org/netbeans/modules/java/bridge/ElementImpl.java new revision: 1.27; previous revision: 1.26
OK, the reported part is fixed now, but I can't help myself: 1. Why are you using double checked locking pattern? it doesn't work reliably and is unnecessary complicated. 2. Why do you lock it on "this", when "this" is each time a different instance, so you're effectively not locking at all?
Locking should be fixed now: /cvs/java/src/org/netbeans/modules/java/bridge/ElementImpl.java new revision: 1.28; previous revision: 1.27