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.
While working IZ: 112233, I saw a lot of activities on lookup in the thread-dump, I'm not sure where the problem is. Definitely some changes in recent past causes this. This used to work before w/o issues. Attaching thread-dump for evaluation.
Created attachment 46357 [details] multiple thread dumps
Let me rephrase the summary. IDE doesn't freeze but performance is really bad after few right clicks.
Created attachment 46358 [details] one more dump
If it is a regression according to you it would be great to tell when it appeared.
Looking at the symptomps and the thread dump, it seems the problem is in a growing chain of nested lookup. Please check the content of the proxy lookup tree after few iterations. Most suspicious is the lookup source implementation in retriever.catalog.Utilities.createModelSource It creates new instance of (pretty complicated) ProxyLookup everytime somebody performs lookup on the outer component. Please see the javadoc of Lookups.proxy: ...checks every time ... whether the provider still returns the same lookup... (which it doesn't!) ...must be thread safe and fast, will be called often... (doesn't look fast to me)
I still do not know where the problem is. Perhaps you guys can help me out. I do get an assertion from lookup, see IZ 112574. Also I'm attaching one more suspicious trace, hoping it'll give you some clue.
Created attachment 46467 [details] one more trace from lookup
The assertion error you linked makes my suspicion that one proxy lookup gets included inside its own delegates. The best thing to evaluate this problem is to force the IDE to bad (already slow) state and take a heap dump. One can then easily analyze the lookup chain used in the node. You can also try quick check by freezing (caching on the first call and returning the same instance) the output of the abovementioned Lookup.Provider in Utilities.createModelSource and trying to reproduce the problem. All in all Utilities.createModelSource is certainly wrong, in one way or other, but the described hack is hardly the correct fix. I can extend on this topic if you wish...
Utilities.createModelSource() hasn't change much between 5.5 and trunk and I do not see this problem in 5.5, nor in 5.5.1. So my guess is, there is some other thing that influences the odd behavior. I've narrowed it down to the "refactoring" related actions. These are new additions to the context menu in 6.0 and guess what, removing those actions (temporarily) fixes the problem. Let me dig further....will talk to you if I can't figure out.
Forgot to mention, even M10 build doesn't have any such problem, that makes me feel that the problem is somewhere else.
Attaching one more trace, could it be related to refactoring?
Created attachment 46533 [details] traces from refactoring
This fix can help Checking in RefactoringGlobalAction.java; /cvs/refactoring/api/src/org/netbeans/modules/refactoring/spi/impl/RefactoringGlobalAction.java,v <-- RefactoringGlobalAction.java new revision: 1.8; previous revision: 1.7 done Please test and let me know.
jbecicka: Well, I was horrified when I saw the original code. Yes, combining the lookups using ProxyLookup is right, although I don't fully grasp the need for such a complicated way of passing single boolean flag. Samaresh: I still think that the refactoring action is just triggering the buried problem (by doing lookup(Object.class), which is a legitimate call). It doesn't explain the gradual slow down, so I'd still like to see a heap dump after few iterations with the old refactoring code.
Imho the bug is here: at org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:651) at org.netbeans.modules.xml.retriever.catalog.Utilities._getDocument(Utilities.java:500) at org.netbeans.modules.xml.retriever.catalog.Utilities.access$000(Utilities.java:82) at org.netbeans.modules.xml.retriever.catalog.Utilities$1.getLookup(Utilities.java:641) at org.openide.util.lookup.SimpleProxyLookup.checkLookup(SimpleProxyLook the XML module tries to open some document inside the lookup query. Please do not do such expensive operation inside of lookup queries.
The fix works, verified. Thank you.
*** Issue 112233 has been marked as a duplicate of this issue. ***
Verified