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.
Created attachment 105436 [details] thread dump
Information about NB: >Log Session: Friday, January 28, 2011 6:49:56 PM MSK >System Info: Product Version = NetBeans IDE Dev (Build 110128-131a01cfbfd4) (#131a01cfbfd4) Operating System = SunOS version 5.10 running on x86 Java; VM; Vendor = 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_20-b02 Java Home = /usr/jdk/instances/jdk1.6.0_20/jre System Locale; Encoding = en (nb); ISO646-US
Seems similar to bug #194748, which does not contain heap info. From this thread dump, it seems that the tenured ("old") generation on heap is almost full. So, a possible problem is a memory leak and the JVM may be under a great stress trying to free some space there. As this seems to happen with a C/C++ source, I would like to ask you to take a heap dump next time the problem occurs and analyze it (or at least check that there is no cnd-related leak). Otherwise, as there probably is no actual deadlock, thread dump is not enough to evaluate and some kind of steps to reproduce are needed. Thanks.
*** Bug 194748 has been marked as a duplicate of this bug. ***
Created attachment 105510 [details] list of the biggest objects from heapdump.hprof
Editor consumes about 20K for each line of edited file. It should be reduced at least in 100 times.
Hi Alexander, could you please test build *201102010000* on http://bits.netbeans.org/dev/nightly/ whether you notice any improvements? Thanks.
Alexander, is there any way to reproduce the problem? Until we get the steps I mark it as P2.
(In reply to comment #7) > Alexander, is there any way to reproduce the problem? Until we get the steps I > mark it as P2. I'm waiting for propagation of changes into cnd-main.
Not fixed. Step to reproduce: - download ACE+TAO sources - build - create project from binary file ACE_wrappers/build/TAO/tests/IDL_Test/.libs/main - Open interfaceC.cpp (24K lines) - do something like "insert space", {"move cursor on CORBA", "reformat", "move cursor on Boolean", "undo"}. Repeat action in {}. After some steps number of "MultiMark+ParagraphView+BasePosition" are dramatically increased and UI is frozen. IMHO key moment: editor update content in parallel with updating annotations. In this case number of "MultiMark+ParagraphView+BasePosition" increased at least in 20 times and we have OOM.
Alexander, is this beta stopper?
(In reply to comment #10) > Alexander, is this beta stopper? No.
I'm already working on this but it leads to non-trivial changes to annotations handling in the editor.
not stopper for beta -> P2. P2 still means stopper for fcs
The fix requires to stop reposting of annotation adding into EDT (it used to be necessary for legacy DrawLayer rendering but is no longer necessary for highlighting layers and current view hierarchy). The replanning complicates the whole process of annotations attaching and the other incoming requests in EDT (modelToView(), painting etc.) result in a slow down unacceptable for large files. The change is also beneficial for NbEditorDocument's code since there used to be a hack because of the EDT re-planning due to possibly reversed order of attaching/detaching coming in EDT. The only impl of NbDocument.Annotatable should be NbEditorDocument (which is now rewritten) and the openide.text tests pass. The change is documented in openide.text apichanges. http://hg.netbeans.org/jet-main/rev/db82e4e0fbcc
Integrated into 'main-golden', will be available in build *201102080000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/db82e4e0fbcc User: Miloslav Metelka <mmetelka@netbeans.org> Log: #194816 - UI freeze on refresh annotations.
*** Bug 194859 has been marked as a duplicate of this bug. ***
Sorry, but original bug did not fixed. As I understand change set removed restriction of "attach/detach in EDT". So to fix original bug you should do one of following: - fix client code (for example AnnotationsHolder in cnd and java clusters) - create bugs against "attach/detach" clients - reassign bug to cnd I would suggest another way to fix bug. First of all I want to note that root cause of problem is: - low performance of adding/removing one annotation. I believe that adding/removing collection of annotations can be implemented as fast as adding/removing one annotation. So to fix problem provide document efficient method that add/remove collection of annotations.
Created attachment 107744 [details] java example of low performance of editor Extract project, open in NB and open in editor file Big.java. See a bunch of editor problems that C/C++ user have in real projects.
Created attachment 107747 [details] C++ sample Open Big.cc file
Regarding Big.cc it seems that there's some performance problem in cnd - a thread "Provider asynchronous-merger prosess" keeps CPU at 100% for rather long time. I've entered issue #197739.
Note that the Java's AnnotationHolder adds/removes the annotations off-AWT in 7.0. On the provided. There appear to be some problems on Java side - Mila filled #197743.
For Big.java there's some hints related stuff computation. I've entered issue #197743. Anyway regarding editor's annotations handling the o.n.editor.Annotations is definitely a candidate for performance improvements. For example it's not necessary to compute annotations combinations on a line until the line is about to be displayed. I have entered issue #197747 for that.
Integrated into 'main-golden', will be available in build *201104200000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6aef47a064ac User: Jesse Glick <jglick@netbeans.org> Log: #194816 change entry was missing its summary.
Dup of issue #197534 since Annotations highlighting layer will have fixed size so annotation changes should not trigger view rebuilding. *** This bug has been marked as a duplicate of bug 197534 ***