Bug 222114 - After Adding an Interface-Methode, NetBeans got´s unresponseable
After Adding an Interface-Methode, NetBeans got´s unresponseable
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Source
7.3
PC Windows 7
: P2 (vote)
: 7.3
Assigned To: Jan Lahoda
issues@java
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-14 14:00 UTC by stefan79
Modified: 2012-11-21 13:48 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Log-file/ThreadDumps/ApplicationSnapshot (67.11 KB, application/binary)
2012-11-14 14:02 UTC, stefan79
Details
Path to GC root for Symtab#1 and #4 (4.74 KB, text/plain)
2012-11-16 14:39 UTC, Tomas Hurka
Details
Log-File. (168.79 KB, application/octet-stream)
2012-11-19 15:23 UTC, stefan79
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stefan79 2012-11-14 14:00:50 UTC
[ 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.
Comment 1 stefan79 2012-11-14 14:02:58 UTC
Created attachment 127782 [details]
Log-file/ThreadDumps/ApplicationSnapshot
Comment 2 stefan79 2012-11-14 14:50:07 UTC
While NB was hanging, I created a HeapDump-File (jvisualvm).
File was uploaded to Hudson: 
http://deadlock.netbeans.org/hudson/job/upload/104/
Comment 3 Marian Mirilovic 2012-11-14 16:51:19 UTC
Reassign to performance team for further evaluation ...
Comment 4 Tomas Hurka 2012-11-15 12:21:39 UTC
There are 4 instances of SymTab.
Comment 5 Tomas Hurka 2012-11-16 14:38:00 UTC
Symtab#1 and Symtab#4 are suspicious. See attached path to GC root for those two instances.
Comment 6 Tomas Hurka 2012-11-16 14:39:12 UTC
Created attachment 127939 [details]
Path to GC root for Symtab#1 and #4
Comment 7 Tomas Hurka 2012-11-16 14:40:11 UTC
Reassigning to java for further evaluation.
Comment 8 Tomas Hurka 2012-11-16 14:43:09 UTC
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.
Comment 9 Jan Lahoda 2012-11-16 22:18:54 UTC
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
Comment 10 stefan79 2012-11-19 15:23:02 UTC
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/
Comment 11 Tomas Zezula 2012-11-19 18:28:56 UTC
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).
Comment 12 Tomas Zezula 2012-11-20 22:11:05 UTC
Restored the behaviour of LowMemoryWatch not to cross the CMS stop the world limit.
jet-main fdbf73f77a1d
Comment 13 Quality Engineering 2012-11-21 13:48:15 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo