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.

Bug 224631

Summary: Leaking JavaC - 748M of occupied memory
Product: platform Reporter: Jaroslav Tulach <jtulach>
Component: FilesystemsAssignee: Jaroslav Tulach <jtulach>
Status: RESOLVED FIXED    
Severity: normal CC: jlahoda, mmirilovic, pjiricka
Priority: P2    
Version: 7.3   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:

Description Jaroslav Tulach 2013-01-09 09:27:42 UTC 
I have new built from Jan 7, 2013 and I've just run out of memory. The CPU usage is (almost) zero, but the memory seems to be occupied persistently. Here is the heap dump:

http://beetle.cz.oracle.com/~jtulach/leaking-javac.hprof.gz

I am assigning to Java as I could see JavaC classes in the histogram's top ten:

 num     #instances         #bytes  class name
----------------------------------------------
   1:         82222      156658832  [I
   2:       1498113      129043352  [C
   3:        138318       93384072  [B
   4:       1724029       41376696  java.util.HashMap$Entry
   5:       1430180       34324320  java.lang.String
   6:        233895       32125224  <constMethodKlass>
   7:        128429       21266224  [Ljava.util.HashMap$Entry;
   8:        233895       18720696  <methodKlass>
   9:        694426       16666224  com.sun.tools.javac.util.SharedNameTable$NameImpl
  10:        268966       16335776  [Ljava.lang.Object;
  11:         24891       16055496  <constantPoolKlass>
  12:        998061       15968976  java.lang.Integer
  13:        209671       15096312  com.sun.tools.javac.code.Symbol$ClassSymbol
  14:        226576       14500864  com.sun.tools.javac.code.Symbol$MethodSymbol
  15:        825982       13215712  com.sun.tools.javac.util.List
  16:         82987       12571832  [S
  17:        505695       12136680  com.sun.tools.javac.code.Scope$Entry
  18:        241274       11581152  com.sun.tools.javac.code.Type$ClassType
Comment 1 Jan Lahoda 2013-01-09 09:35:20 UTC 
Forbidden
You don't have permission to access /~jtulach/leaking-javac.hprof.gz on this server.
Comment 2 Jan Lahoda 2013-01-09 15:28:16 UTC 
I did not have time to go through all 49 instances of javac in the dump, but after inspecting 10+ of them, it seems that the javac's are held through LayerGeneratingProcessor.originatingElementsByProcessor (read: this map holds 10+ useless javacs). I don't think there is a better solution than to fix LGP not to hold old javacs. The only real alternate solution I know would be to use a brand new AP Class loaded anew for each run of javac, but editting would be extremely slow (and esp. for NB APs, which typically force loading of tons of classes, just to provide the annotation names they are interested in, to find out they should not be called - but would cause problems to eclipselink as well).
Comment 3 Jaroslav Tulach 2013-01-09 15:46:02 UTC 
I see. Thanks for the evaluation.
Comment 4 Jaroslav Tulach 2013-01-10 07:37:14 UTC 
ergonomics#0a0a4941bdc8
Comment 5 Antonin Nebuzelsky 2013-01-10 15:57:42 UTC 
Obviously too late to be in release73 branch already. Changing TM=Dev.
Comment 6 Quality Engineering 2013-01-11 03:02:05 UTC 
Integrated into 'main-golden', will be available in build *201301110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0a0a4941bdc8
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #224631: Using WeakSet instead of ArrayList
Comment 7 Jaroslav Tulach 2013-01-14 10:03:01 UTC 
Merged as

changeset:   b13bd4b8b257
branch:      release73
Comment 8 Quality Engineering 2013-01-14 19:09:51 UTC 
Integrated into 'releases', will be available in build *201301141642* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/0a0a4941bdc8
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #224631: Using WeakSet instead of ArrayList