Created attachment 107340[details]
NB 7 RC1 Threrad dump
This problem has been there for a while.
After interrupting a debugging session, NB becomes sluggish and a single operation (even just a click on a button) can require a few seconds
The w/a is to restart NB.
I have attached a Thread Dump.
The debugger session is not fully stopped yet - there's still visible activity of retrieval of variable values that are probably displayed in Variables or Watches tab. It'd be better to have a profiler snapshot.
AWT thread is doing repaint of a debugger table with data, do you still have some debugger window opened?
Do you have some concrete steps how we can reproduce it?
NOW I AM USING NB 7.0 released to NetCAT members.
It is not due to an interruption of the debugger but happens after running debugging sessions to completion.
Whatever the reason is, I must restart the IDE because every UI action requires seconds to execute. Hence, I have raised the priority to 2.
It's a pain to search for the problem in 40MB XML file. Where I do not see the CPU time.
However the problem does not seem to be in debugger. The time spent in debugger classes is under 10%.
AWT is busy with repaints of editor and other windows, but the time spent there is also low.
There's an ongoing Java parsing, which seems to consume most of the time.
25% of the time is spent in DiffSidebar
Moving to parsing for evaluation...
Does not have anything in common with parsing api.
There is some java parsing which Martin pointing on but it seems to be just file reparse (blocked by VCS). It's really hard to find something in 40 MB XML file which nothing except vi can open.
It may be a memory leak and time is spent in full gc.
Please attach the nps file as Martin requested before and netbeans log file.
The memory usage will be also welcomed (how much of the heap is used?).
Without this info it's even impossible to assign the bug to correct category.
Thanks in advance
I will be very happy to give you the nps file if you just explain to me how to get it.
In order to produce the xml file I folowed the instructions published here:
I have no problem opening the file. I am on windows. Use TextPad for example. It is very fast.
This problem happens very, very often and is very annoying.
Please note that I open bugs in the interest of the NetBeans Community because I think NetBeans is a great product.
The NetBeans Community is all of us.
Comment 10Martin Entlicher
2011-04-19 22:07:54 UTC
When you generate the Profiler snapshot, please press the save icon (Save Snapshot to Project), then go to Info tab and copy the File path. Attach that file here please. Or use Export to... but be sure to select "Profile Snapshot File (*.nps)" file type.
Thank you very much for the data.
It seems that my estimate was right the debugger session created a memory leak. When the heap usage is over ~ 70% the hot spots switches from concurrent gc to stop the world gc (when gc is running all the other threads are stopped). As there is a leak and hot spot is not able to free any reasonable amount of memory it repeats the gc cycles.
As I sad before it has nothing in common with parsing.api the debugger or something leaked the memory there is only 10MB free on the heap (386.2/396.4 MB). There is no parsing.api running there is only java hints running on single file which took 12sec but it's cancellable task which is canceled as soon as you start type in the editor. It takes so long because the gc cycles.
Now I will need a heap dump which is a bit harder task.
First you need to get the IDE into the sluggish state
Then from command line find out the netbeans process id:
it should print something like:
where the Main should be the IDE
After it run:
jmap -dump:format=b,file=heap.bin PID
in my case PID = 578
it will create a file heap.bin which contains the heap dump.
Then you need to share the file somehow. Unfortunately the issuzilla does not
allow such a big attachments (it will be quite big file) but you can use magashare or some other
If you have any questions feel free to ask.
The most of memory is occupied by subversions DiskMapTurboProvider what I have no idea what it is. There is also 8 javac instances I will look at javac instances and then reassign (or create a new issue) for the subversion.
The second heap dump is a bit different.
There is also lots of string hold by subversion (80MB) and there are also strings hold by Tomcat support.
The debugger still holds lots of sting in "Debugger operator thread" by Operator class, which seems to me as a bug as you ended the debugger.
It seems that the biggest problem is in Subversion and debugger.
If you have some time can you create application snapshot (it shows the VM statistics)?
You will need a VisualVM, you can download it here: http://visualvm.java.net/
Then you start the visual vm in the Applications (Local) select NetBeans and choose "Open".
Then you start debugging and finishes it and do some work to see if the IDE is slow.
Finally in VisualVM you invoke "Application Snapshot" on NetBeans (in pop up menu)
In VisualVM in Applications under the Snapshots node a new sub node appears and it has "Save As..." action.
Please attach the snapshot.
VisualVM is a great tool. Thanks a lot for pointing me to it.
The Application Snapshot is available here:
The second testcase I uploaded refers to a different set of projects.
The second one is about Java and Java Web applications built with Ant.
The first one was about several Maven projects with thousands of files.
All project files are saved in Subversion repositories.
The degradation of performance is gradual and appears after a couple of hours of work with a few debugging sessions. I cannot tell if the same problem would appear without debugging sessions since these are an integral part of my daily work.
However, it is my impression that it gets suddenly worse just after a debugging session.
Many thanks for your assistance,
The problem with hold source is already fixed 8445662e0bfe by Marek issue #197458.
So the problem is debugger and subversion cache.
The debugger holds string on stack and VCS holds 70-80MB in some cache.
I will look to the newest snapshot and then reassign to debugger which should evaluate it is could not clean the stings when debugger connection is closed and reassign to subversion.
Comment 31Martin Entlicher
2011-04-27 12:40:25 UTC
The WeakHashMap should be cleared by SessionsListener, which was already introduced by http://hg.netbeans.org/main/rev/d27b2e964744
One problem is, that the last debugger session did not really finish.
There is still "JDI Target VM Interface" thread waiting at SharedMemoryConnection.receivePacket0(Native Method) and "JDI Internal Event Handler" waiting at EventQueueImpl.removeUnfiltered(EventQueueImpl.java:189).
Probably due to this fact "Debugger operator thread" can not be finished and is waiting at EventQueueImpl.removeUnfiltered(EventQueueImpl.java:189). On the stack it's holding JPDADebuggerImpl, whose state is still STATE_RUNNING.
That last debugger session holds all previous debugger sessions through lookup maps. This is something that needs to be fixed.
Comment 32Martin Entlicher
2011-04-28 12:36:46 UTC
I've solved the memory leak in debugger by changeset: 193131:852caaee8478
If there are some strings being held by "JDI Internal Event Handler", it's a JDK problem and it's not solvable in NetBeans.
Passing to Subversion to solve the 80MB subversion cache.
uff, you seem to store thousands of files in a versioned context. And what is worse, they are not yet committed but "locally new", which means they have an interesting status for us/you. Such files are offered in the commit dialog when you try to commit your project.
You see, subversion keeps information about such interesting files in a cache and if the number of them grows to a certain limit, well, then the memory gets stuffed.
The files lie in E:\quaglan\My Documents\projects\subversion\sdi3\Geoportal\trunk\Services\MavenProjects\InspireWebServices\*. You can inspect those files if you run Subversion -> Status on the folder in Favorites. Do you keep them intentionally in the versioned context? I suggest you either:
1) commit them if they're needed and intended to share with others
2) svn ignore the folder
3) delete all those files
When you chose and performed one of my suggestions, please delete also ~\.netbeans\7.0\var\cache\svncache and restart the IDE.
If you're not happy or satisfied with the suggested solutions, please provide more information about the files, why you keep them, what are they used for, etc.
I understand, your explanation is fine for me.
I generate the files during the unit testing but I delete them before committing.
So I would say this is OK.
I would like to know when and where I will be able to download a build containing the debugger fix as explained above so that I can give a feedback about it.
Many thanks indeed,