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.
[ JDK VERSION : J2SE 1.4.2_05 ] i opened jtable for example. whe i try to scroll, from time to time the editor is frozen for 0.5 - 1 seconds. after scrolling the complete file it starts to behave normally. this was with 1.4.2. with 1.5 it behaves better, but there are still some freezes in the beginning.
Do you mean the scrolling immediately or shortly after the document was opened? Are you sure that scrolling till the end resolves the problem? Couldn't you instead wait for several seconds e.g. 10secs in case of JTable and then try to scroll whether the same problem occurs? Thanks. There are a lot of things going on right after the file opening - the document gets parsed; the code folds get constructed; java navigation view in the editor's toolbar gets populated etc. All these things are done in the background but they influence responsiveness of the IDE.
i tested a little bit with a few jdk classes (JTable, JEditorPane, JScrollPane) and found out that there is some common behaviour: after opening these files the ide gets really slow for aprox. 15 seconds. it seems that during this time some really intensive operations are going on. the memory toolbar shows at least pretty intense garbage collecting activity. what i can see is that the editor toolbar's combobox is populated in 1-2 seconds, the same goes for the folds showing on screen. of course, i don't know if all the folds were computed, i can only tell that i see the first fold being painted after 2-3 seconds. 2-3 seconds would be of course fine, but 10-15 is pretty bad. my computer's specs are not so bad too: 2600+ AMD Athlon 512 MB Ram 2.6.7 kernel
ah, forgot to say that this behaviour is for 1.4.2_05 with 1.5 (build 60) it behaves a little bit better (the times i described are shorter)
some additional testing with really bad results (OutOfMemoryError), so i'm making this a P1: 1) i start the IDE with no open file in the editor and the refactoring an with all his dependencies projects open. i have around 48-50 MB heap. 2) i open JTable, memory climbs till 110 (of 127.1), then after some CPU intensive tasks (which i already described) goes down to 67-70. 3) i open JComboBox, max of memory i can see in the memory toolbar is 120, then it goes down to 70. 4) i open JEditorPane memory goes till 125, and in the console i see the first OutOfMemoryError 5) open JScrollPane, the second OutOfMemoryError after these errors the heap usage goes always down, with those 4 files open there are 85MB of heap used. maybe not a editor problem.
As a quick fix for OOME, so you can continue to evaluate and use 4.0 beta or Dev, change the setting in your netbeans\etc\netbeans.conf for heap size to -J-Xmx160m If you have enough memory and you want to tune overall performance, you can make this number even bigger (-J-Xmx256m, as an example). If you are building it from CVS, you can change it in ide\launcher\netbeans.conf so you don't loose your setting everytime when you make a new build.
I think that there is a leak and we need to find out where it is. Dusane, please search for leaking NbEditorDocument instances in OptimizeIt. Added Martin to cc if he wants to investigate java side.
I'm trying to run the IDE with -J-Djavacore.debug.transactions=true switch to see what's going on right after a file opening. I can see there is a lot of stuff originating in the toolbar's navigation view populating, followed by Java node hierarchy updates, annotations computing, and folds repainting. However, after the folds repaint (2-3 seconds after the file opening) IDE becomes fully responsive again (no 15 seconds of intensive computing, no OOME) on my machine (j2se 1.4.2-b28, -J-Xmx128m, Linux 2.4.22 kernel). So, could you please run your IDE with the above mentioned switch, see whether is there any console output in 10-15 seconds after the folds repainting, and possibly attach the console output to this issue? Thanks.
CC'ing Tom since the high increase of needed memory shortly after file opening may also be caused by the parser that underlines errors.
Think I suggested this in some other issue, but...the navigation view is a combo box - it only really needs to know all of the methods of the file when the popup is opened. The rest of the time it only needs to display the name of the member the caret is in. Might be better to use a regular combo box with a custom model that will lazily resolve its contents, rather than ChoiceView - since most of the time that combo will never be touched, it doesn't need to be populated aggressively.
To Tim: the model for navigation view is computed out of the awt event queue now. So it should not block.
to me the problems seems to be related to garbage collection. heap goes up very fast (from 30MB to 100+MB) when opening such a big file. the editor behaves normally during this time (excepting the initial 2 seconds). but when the heap reaches dimensions comparing to the maximum value (which now seems to be 128MB) the IDE becomes really sluggish. why is there such a heap increase in such a short time?
Leon, could you please also try to take several JVM thread dumps during those initial 10-15 seconds and attach them to the issue? Thanks.
Mila, according to OptimizeIt, there are no NbEditorDocuments leaking. After opening and closing several files, there is only one instance of NbEditorDocument left (the instance created by JavaKit.createDefaultDocument()).
I think Leon is right. I played w/ that again and realized that there is a big difference in 1.4.2 and 1.5 on my machine. The memory usage in 1.4.2 is really going up fast. It eats everything up to 128 limit (even without scrolling!, so it's not related to repaint or changes in NavigationView). The garbage collector freezes the for 1-2 secs than and memory is on cca 60MB (numbers can vary, depends on hte number of open project). Sometimes it goes through similar cycle 2x or3x (maybe more) and leave the memory meter on last value. If you force GC (by clicking on MemoryMeter), it collects objects back (or it seems so, I don't have precise numbers). 1.5 is oscillating between 54MB and 65MB (again, don't take total numbers), but it never goes to 128 limit.
Created attachment 17172 [details] thread dumps during non-responsive periods
When I run it w/ -J-verbose:gc there is no Full GC when opening the file in 1.5. When running the same build on 1.4.2, there is either 1 or 2 Full GCs during opening the file.
So let's focus on 1.4.2 now. I switched off Code Folding in Options Dialog -> Full GC is still there I switched off Editor Toolbar -> Full GC is still there I run the IDE with -J-Djavacore.debug.transactions=true to check whether codefolding and NavigatioView is really OFF and there is no call to ExclusiveMutex from these features and indeed, there is no call from these features, but there is a lot calls with the same stack trace: ... org.netbeans.mdr.NBMDRepositoryImpl.beginTrans(NBMDRepositoryImpl.java:232) org.netbeans.modules.javacore.JMManager.getFileObject(JMManager.java:438) org.netbeans.modules.javacore.JMManager.getDataObject(JMManager.java:461) org.netbeans.modules.java.JavaNode$PropL.resourceParsed(JavaNode.java:246) org.netbeans.modules.java.JavaEditor$WParsingListener.resourceParsed(JavaEditor.java:2756) ... I tried to count them, but I gave up somewhere around 70. I was opening ImageIcon and I used Favorites tab, where I added src.zip from 1.5, expanded the tree to javax/swing folder (no project was open at that time). The folder contains all swingx java files, so I suspect that the call was made for each node in the tree. Not sure if it causes the memory consumption.
I've got the bunch of the same calls even without opening the file. Simple click was enough to start the storm of messages, but these calls didn't cause the memory consumption. Test case: - click on the file (Box.java as an example) - wait until all debug messages are gone (memory is still OK) - dblclk and open it -> memory is growing
Assigning to java/javacore for evaluation, it seems to be related to background parsing, rather than editor itself.
Assigning to pflaska. Pavle F, can you evaluate following test case in profiler: - 1.4.2, CodeFolding: OFF, Editor Toolbar: OFF - add src.zip from 1.5 into Favorites - expand the tree to javax/swing folder - click on Box.java (or any other java file) and wait CPU gets down - open file We need to find out why the memory is growing and GC occures and if we can eliminate it
Neither Leon's nor Pavel's test case are reproducible on my machine. I roughly went through thread dumps and saw some strange things - there are a lot of error annotation computing and I saw also often VCS things in it. -- Will continue with investigating with VCS support. (Currently I use local files and jar files in my testing.)
I have done another investigation. I have found that there are not problems neither with VCS nor with error annotation. Blocking is really caused by full gc. There is visible difference between 1.4.2 and 1.5, which is IMO caused by better and faster VM implementation in 1.5. The growth of consumed memory when opening file is really huge. Unfortunatelly I have not found anything useless yet, a lot of memory is consumed by parsing. BUT: Martin has finished many optimalization in memory consumption, see issue #43258. This should help to solve this issue as a side-effect. (The number of full gc should be smaller.) It would be fine if anybody who experienced this problem could try today's build.
so, my impression after getting the latest changes (related to issue #43258): it got better, but it's not yet there where it should be. the positive thing is that i did not get the OOME's although i opened quite a lot of big files. but memory still goes up like hell after opening such a file, then gc kicks in and reclaims much of the memory. this is still a issue in my opinion.
Agreed that this is still an issue. Although I am affraid we will be able to do more about it for 4.0. Most of the memory seems to be consumed by the parser - ASTs for big files are big. Anyway, let's keep this issue open and try to improve this in the next release. For now, let me give this issue a lower priority since IMO it no longer causes serious problems.
We have significantly reduced the memory usage. AST cache is now very small and the garbage held by parser is now also minimal. So, I believe this issue is fixed.
Reorganization of java component