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 130469 [details] log file Build 201301120001 After a fresh startup and waiting for scanning to complete, shutdown takes only 12 seconds. However, after a whole day session, shutdown may take up to 20 minutes. This happens with NetBEans 7.3, not with 7.1.2 How can I help diagnose this? Would you help me with outlining the steps in detail? I have tried jvisualvm CPU sample but that freezes my PC indefinitely. Perhaps something I can leave running overnight? I need to know exactly what to do otherwise experimenting on my own is hopeless. Do you want a heap dump before I shut down the IDE? My computer is slow - 1.8 GHz single core, 3 GBytes RAM. netbeans_default_options added only -J-Xmx1000m. In the last instance, towards the end of the session, at the end of the day, even with very large pauses (PC in sleep mode) and little work done, NetBeans typically gets very slow. Win NT file system and memory have been identified as bottlenecks on this computer before. I think it is the combination of CPU and memory. However, there was sufficient memory and no other apps running competing for it. I could not observe high disk activity. The computer is in good shape. The NetBeans memory meter is low perhaps 300-500 while the OS shows that NetBeans uses 1GByte. The log shows slow I/O: WARNING [org.openide.filesystems.FileUtil]: FileUtil.normalizeFile(C:\Documents and Settings\name\.m2\repository\org\apache\httpcomponents\httpclient\4.1.2\httpclient-4.1.2-javadoc.jar) took 7,437 ms This is extreme but I woule expect this in this scenario. CPU starvation with multiple threads within NetBeans? No other processes are using any significant CPU or I/O at this time.
If even sampling from VisualVM is not possible, please take some thread dumps for example every minute or so, so that we have some idea of what is going on during the shutdown.
Created attachment 130602 [details] 4 Thread dumps in zip file Could not make the thread dumps the way I wanted - jvisualvm responded too slowly. Will try to get more next time.
Created attachment 130676 [details] 8 thread dumps in zip file Thread dumps with a better time distribution
I had a quick look at one of the thread dumps. Count: 140. I am not convinced that they are all doing anything except slowing down my computer. Some are obviously sticking out because their names are identical: Count 5 of: Inactive RequestProcessor thread [Was:JaxWs-maven-request-processor/org.netbeans.modules.maven.jaxws.nodes.JaxWsNodeFactory$WsNodeList$1] Count 6 of: Inactive RequestProcessor thread [Was:org.netbeans.spi.project.ui.support.NodeFactorySupport/org.netbeans.spi.project.ui.support.NodeFactorySupport$DelegateChildren$2] Count 15 of JPDA Debugger Count 32 of org.glassfish.tools.ide.server.FetchLogPiped[C:\Program Files\glassfish-3.1.2.2\glassfish;C:\Program Files\glassfish-3.1.2.2\glassfish\domains\domain1]deployer:gfv3ee6wc:localhost:4848 To shut the IDE down at the end of the day takes 20 minutes vs 20 seconds normally after a warm-up period of 30 minutes with all features used once. Performance before shutdown is .. well I don't have any words for it. So to get reasonable performance I guess I have to re-start NetBeans every 2 hours?
It looks like an accumulation of unnecessary tasks that run in the background, cunsuming memory and CPU whenever I start any activity. At the end of the session, even for a new project, I see in the log multiple subsequent entries like WARNING [org.openide.filesystems.FileUtil]: FileUtil.normalizeFile(....\AnagramGame\src\com\toy\anagrams\ui\Anagrams.java) took 562 ms. ... (twice in this case) even for a new project that I opened just to see why. For older project files I have seen up to 5 subsequent entries. So it looks like multiple threads are performing expensive operations for no apparent reason.
Does it still happen after fixing of issue#225157 ? If it does, can you please upload heap dump from the time?
I don't have the heap dump. However there are thread dumps which could be exploited for analysis. Would you mind commenting on the number of threads (140)? The number of threads is a leak in its own right. Which issue (the one being closed fixed) are you referring to? Not this one?
the threads are mostly harmless - they are just waiting on background. The only threads which stuck out as odd are the jpda debugger threads, but that problem should be resolved by issue#226565 (sorry wrong link in previous comment), that's why I asked whether the problem is still there after the fix of that issue. And if it is to perhaps upload a heapdump.
Sufficiently covered by duplicate which has a heap dump and a reproducible test case. In hindsight, this thread dump clearly contains threads leaked by the two issues: debugger threads and GlassFish threads, both of which can cause OutOfMemoryException individually. I think we have reasons to celebrate. I would expect a reduction of other performance issues that were caused by CPU starvation due to garbage collection etc.. *** This bug has been marked as a duplicate of bug 228886 ***