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.
[ BUILD # : 201211140001 ] [ JDK VERSION : 1.7.9 ] I´ve added a Methode to an interface (interface have 5 implementations). After adding the new method to the first source-file, the IDE was slower. After adding the second java-file, the IDE doesn´t responses a long time (> 30 minutes). The cpu-usage was very high (~80-95% at 4 CPU´s). Memory-Usage was also high. After about 45 minutes, I killed NB.
Created attachment 127782 [details] Log-file/ThreadDumps/ApplicationSnapshot
While NB was hanging, I created a HeapDump-File (jvisualvm). File was uploaded to Hudson: http://deadlock.netbeans.org/hudson/job/upload/104/
Reassign to performance team for further evaluation ...
There are 4 instances of SymTab.
Symtab#1 and Symtab#4 are suspicious. See attached path to GC root for those two instances.
Created attachment 127939 [details] Path to GC root for Symtab#1 and #4
Reassigning to java for further evaluation.
Besides those 4 instances of SymTab, messages.log shows that the low memory detector does not work well in this situation - this is probably caused by high Xmx.
I think the low memory detection is the main problem - the two above instances of javac may present minor problems, but do not seem to be very significant to me. From what I think I see in the dump (writing the numbers from my memory, as I had to close the profiler already), there is indexing going on, which tries to process ~14000 files in total and is probably somewhere around ~6100 files already attributed/processed. A line from the low memory watch: FINEST [org.netbeans.modules.parsing.lucene.support.LowMemoryWatcher]: Max memory: 1.984.167.936, Used memory: 1.820.452.320, Low memory condition: false The memory allocation is well above the 80% of heap (1.587.334.349), but there is still ~156MB "free", which is more than the current hardcoded minimal limit for low memory (~100MB). So the low memory watch won't stop the processing because it thinks there is still enough memory. But I am not sure if that is true: I tried to run the IDE with -Xmx2048m, and was easily able to grow YouGen to almost 400MB (see below). So in the situation in the dump, the VM may actually be under a lot of stress, as the OldGen is probably quite full, probably with GC running very often over it. So I guess we will need to balance the LMW to handle these situations better. My heap spaces allocation of a test run: Heap PSYoungGen total 387328K, used 277201K eden space 308672K, 89% used from space 78656K, 0% used to space 83328K, 0% used ParOldGen total 188224K, used 103527K object space 188224K, 55% used PSPermGen total 130624K, used 95270K object space 130624K, 72% used The md5sum of the heap I looked at is: 39f29d3dcc0ea93df01f821d00795a2c
Created attachment 128071 [details] Log-File. Today the OutOfMemoryError occured again (after adding a Method to a Utiliy-Class). Dump was uploaded to hudson: http://deadlock.netbeans.org/hudson/job/upload/109/
Yes, it's also related to the issue http://netbeans.org/bugzilla/show_bug.cgi?id=221357. I've written there the LMW has still enough memory (200MB) but the GC is trying hard to get some free space. I will return back to original state where the LMW was always below the CMS GC stop the world. I will do it tomorrow, feel free to reassign the issue(s).
Restored the behaviour of LowMemoryWatch not to cross the CMS stop the world limit. jet-main fdbf73f77a1d
Integrated into 'main-golden', will be available in build *201211211016* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fdbf73f77a1d User: Tomas Zezula <tzezula@netbeans.org> Log: #222114:After Adding an Interface-Methode, NetBeans got