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.
Every time I modify and save my Java file (NetBeans code: mercurial/src/org/netbeans/modules/mercurial/options/MercurialOptionsPanelController.java), the Java parser is activated and reparses something. It takes approx. 3-4 seconds, which would be acceptable on a quad-core machine, but it blocks the AWT thread! I also found that my IDE consumes a lot of memory and it seems to be garbage-collecting quite often - maybe it is related to the problem with frequent parsing. I am attaching output from jmap a thread dump. I have also saved the heap dump if anyone is interested.
Created attachment 81104 [details] output from: jmap -heap
Created attachment 81105 [details] thread-dump
Created attachment 81106 [details] screenshot of the summary view in VisualVM
Created attachment 81109 [details] screenshot of the classes view in VisualVM
Fighting with the same issue for two weeks, but haven't been able to reproduce it after IDE restart. I'll attach two Profile Me snapshots I've token in last two days from 200904280200 & 200904290200, Linux Ubuntu 9.04, JDK 6.0 u13 / 64b: - START - typing in the editor - save file -> forces "Scannning project ..." and AWT freeze for 3-5 seconds - you can type into editor again - STOP another scenario is : - START - switch tab in editor forward, backward ... -> forces "Scannning project ..." and AWT freeze for 3-5 seconds - you can type into editor again - STOP
Created attachment 81163 [details] Profile Me - snapshot 1
Created attachment 81164 [details] Profile Me - snapshot 2
The original mpetras' thread dump does not show a blocked AWT. A noteworthy fact from the thread dump is that the MultiPass indexer was used, which strongly suggests that the IDE was tight on memory. It is quite possible that the AWT lag was caused by this situation (GCs, slow painting). The Marian's heapdump contains more that a million instances of com.sun.tools.jdi.Packet and almost one and half million of HashMap$Entries, Strings and char[] and also more than a million instances of byte[]. The instances of these five classes consume ~260MB of memory in total. Quite possibly, there is one instance of each of HM$Entry, String, char[] and byte[] per one instance of the Packet. This could be easily accountable for the near-out-of-memory situation. I took a quick peek at mmirilovic's dumps and the AWT seems to be painting in them. As the problem goes away after restart, the problem may also be caused by near-out-of-memory situation (either the same as the above, or a different one - cannot be said without a heap dump/histogram).
I looked at the profiling snapshots too: first shows almost nothing (only 300ms spent in AWT and Java Source Worker Thread), second shows about 1s in AWT painting something and about 2s Java Source Worker Thread indexing. No AWT blocked in either case. I agree it is likely a near-out-of-memory situation. So probably need to look at the Marian P.'s heap dump, and get confirmation from Marian M. that his IDE was close to memory limits (possibly create histogram/heap dump in that situation).
mpetras, can you add more info?
jlahoda and I talked soon after I filed the issue and I confirmed the IDE had allocated the maximum allowed memory for heap (512 MiB) and that approx 455 MiB of it was in use (see the first attachment). We came to the same hypothesis he wrote here, i.e. that it might be the garbage collector what blocks repainting. The assumed scenario was that every time the file was saved, it triggered reparsing that asked for some memory for heap - this triggered garbage collection, which took 3-4 seconds and blocked repainting for this period of time. If the above hypothesis is correct, then there must be a huge memory leak in the NetBeans debugger or in the JDK debugging subsystem.
ok
This is a duplicate of issue #133049 in fact. Marian, we need steps to reproduce. Without them we can not find the cause. When debugger is running, "JDI Target VM Interface" should be present. Since I do not see this thread in the dumps, either debugger finished normally or this thread crashed. Can you please provide messages.log from the affected session? I wonder if there are some exceptions that could break the JDI thread. There can be also messages "Recieved reply with no sender!" printed by TargetVM.
I am sorry, I do not have the messages.log file available any more. I have restarted the IDE too many times since then. (It might be good to store more then the last three IDE logs.)
*** This issue has been marked as a duplicate of 133049 ***
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.