[ 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
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]
While NB was hanging, I created a HeapDump-File (jvisualvm).
File was uploaded to Hudson:
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:
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:
Created attachment 128071 [details]
Today the OutOfMemoryError occured again (after adding a Method to a Utiliy-Class).
Dump was uploaded to hudson:
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.
Integrated into 'main-golden', will be available in build *201211211016* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Tomas Zezula <firstname.lastname@example.org>
Log: #222114:After Adding an Interface-Methode, NetBeans got