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.
I'm using Product Version: NetBeans Platform 7.0 RC1 (Build 201103280000) Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02 System: Linux version 2.6.35-28-generic running on amd64; UTF-8; en_NZ (test) Userdir: /home/david/.netbeans/nb-dev to develop NB and today I noticed that editor suddenly froze for quite a long time while I was just typing a text in it. I've noticed it because I've never seen it behave like that before. It did not look like it has any reason - everything was parsed, the same file was opened for a long time, I was only editing one file on and off. When it happened last time I was able to capture 5 thread dumps which span about 15 seconds when the IDE was not responding. The thread dumps look very similar and there seems to be lots of editing stuff going on. Two suspicious but likely unrelated things I noticed from thread dumps: * there is 16 "Spellchecker" threads * there is 17 "Inactive RequestProcessor thread [Was:org.netbeans.editor.GlyphGutter/org.netbeans.editor.GlyphGutter$5]" threads
Created attachment 107708 [details] thread dumps
What about the self profiling feature? Any chance to get a profiler snapshot? I mean if it is reproducible somehow ...
Passing to Mila as it seems that document was locked while trying to type and some view hierarchy operations were performed. Milo?
Davide, how big roughly was the file? Don't you remember if there were many annotations or not? Was it a hang or CPU at 100%? Anyway so far there is nothing really suspicious in the thread dumps for me. As David S. said profiling snapshot would be helpful or any steps how to reproduce the problem. Thanks.
(In reply to comment #4) > Davide, how big roughly was the file? The file I was editing was org.netbeans.modules.css.formatting.api.support.AbstractIndenter (2275 lines) as I was fixing several issues there yesterday. Both times when the froze happened I was changing class variables at the beginning. > Don't you remember if there were many > annotations or not? No annotations. > Was it a hang or CPU at 100%? Not sure. IDE was redrawing immediately, just editor caret did not want to move and type remaining letters I just typed. Or maybe it type them one by one very very slowly. Probably not 100% CPU because everything felt quite smooth (my OS and switching between console and IDE) and that's why I filed it as I have not seem this behaviour before. > As David S. said profiling snapshot would be helpful or any steps how to > reproduce the problem. If I see it again I will try to grab a snapshot. So far I believe it was totally random and happened two times in one day on the same file. Btw. why spellchecker is using so many threads? I would expect it to be a "hint" which deserves very low resources.
(In reply to comment #5) > Btw. why spellchecker is using so many threads? I would expect it to be a > "hint" which deserves very low resources. No idea - so far there is one RequestProcessor (with throughput 1) for each spellchecker's ComponentPeer (and there is one ComponentPeer per "important" text component), so whatever happens there shouldn't be more than one Thread per editor, and typically at most one - only one editor is normally "active" and there shouldn't be any really long computation in this RP. I do not know about any actual reason for keeping it this way - it probably never caused any problems so far, so it remained this way. I am going to make the RP static, so that there should be at most one thread at all.
Integrated into 'main-golden', will be available in build *201104150401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/eb9bcdc022ee User: Jan Lahoda <jlahoda@netbeans.org> Log: #197687, #197458: spellchecker's RequestProcessor should not keep sender's stack trace, using only one RP for all ComponentPeers.
I'm working on several performance improvements for the view hierarchy. Once they've got committed we can reinspect the situation.
View hierarchy improvements covered by issue #197534 so marking as dup. *** This bug has been marked as a duplicate of bug 197534 ***