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.
About two weeks ago, I was testing memory consumption by NB6.9.1 vs. trunk, and it appears that the memory consumption of trunk IDE may be higher. The memory consumptions for J2SE build: Step 1 - Testcase trunk NB 6.9 Startup & warmup w/o project Heap (after GC) 24.3 22.3 Used Perm Gen 59.6 59.5 Classes loaded 7290 7326 Step 2 - Testcase trunk NB 6.9 Open j2se project Heap (after GC) 45.9 34.4 Used Perm Gen 100.6 81.2 Classes loaded 12382 9986 Step 3 - Testcase trunk NB 6.9 Open java file, edit, build Heap (after GC) 63.7 50.0 Used Perm Gen 120.7 101.5 Classes loaded 14875 12578 Full build: Step 1 - Testcase trunk NB 6.9 Startup & warmup w/o project Heap (after GC) 19.7 19.1 Used Perm Gen 47.0 48.3 Classes loaded 5657 5867 Step 2 - Testcase trunk NB 6.9 Open j2se project Heap (after GC) 56.8 44.3 Used Perm Gen 105.0 86.8 Classes loaded 12741 10593 Step 3 - Testcase trunk NB 6.9 Open java file, edit, build Heap (after GC) 75.6 60.2 Used Perm Gen 125.0 106.8 Classes loaded 15322 13151 Notes: values are in MB (except for the classes loaded). This should be investigated.
Any progress on evaluating this? Is P3 the correct priority, or should it be a P2?
20% regression can't be P3 ... should somebody from editor team at least evaluate this issue ? If we will not be able to address it to NB 7.0, we have to do so for 7.0.1
Looking at dumps from 6.9 and dev/7.0 (basic cluster), I can see these signification contributions to the increased consumption: -class org.netbeans.modules.html.validation.ValidationTransaction (holding almost 10MB), most of which through its preloadedSchemas static field. This class does not exist at all in my 6.9 snapshot, so it likely was added in 7.0. -in-memory cache for Lucene data (to speed up Go to Type, etc.). AFAIK this is intentional. The cache size is by default limited to 5% of total heap size. -various class-loading related classes/instances (e.g. BinaryFS) appear to consume slightly more memory, which I would attribute to simply having more classes/resources.
(In reply to comment #3) > Looking at dumps from 6.9 and dev/7.0 (basic cluster), I can see these > signification contributions to the increased consumption: > -class org.netbeans.modules.html.validation.ValidationTransaction (holding > almost 10MB), most of which through its preloadedSchemas static field. This > class does not exist at all in my 6.9 snapshot, so it likely was added in 7.0. Already filed: [Bug 196467] New: static field ValidationTransaction.preloadedSchemas holds about 10MB of unGCable memory
Thanks Marek for the pointer. As the in-memory cache for Lucene indices is intentional and provides huge speed benefit. The memory consumed by class/resources caches does not seem very significant and is likely inevitable.