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.
Scenario from issue 51384. I realized there is more CachedPages than should be there (IIRC 128 pages) I've found >1400 CachedPages, referencing together ~3MB of byte arrays. All of the CachedPages are referenced from static ArrayList FileCache.pages, so it seems that the limiting the number of CachedPages is somehow broken. Moreover, some of the CachedPages belong to the databases of closed projects and they keep referencing some other data, like long filename Strings (issue 51504) and other objects related to MDR. This should be at least analyzed and well understood for 4.0
closing and opening the same projects lead to higher and higher number of CachedPage instances.
and the growth is quite high: start with nbbuild/misc - 1458 pages close all - heap goes down to 18MB reopen all - pages go up to 3281 close all - heap goes down only to 24MB reopen all - pages go up to 4922 close all - heap goes down only to 31MB reopen all close all - heap goes down only to 34MB reopen all - pages go up to 7383 close all - heap goes down only to 43MB atd...
I found out that the growing number of pages when having many classpath elements is caused by a per-storage mini-cache of 5 b-tree pages for working with indexes. This means that for the whole nbbuild/misc project consisting of aprox. 320 CP elements 1600 pages can be held by the b-tree cache. This confirms Petr's findings. This problem alone would not be that serious. A bigger problem is that the pages held by the mini b-tree cache are not freed from FileCache when the corresponding storage is unmounted. This results in growing number of these pages when repeatedly opening and closing projects. Tonda says the increment of the used memory is "quite high", which is a relative term. I think it is not high enough to be a showstopper if you consider that it is quite a corner case to repeatedly open and close a project containing 320 classpath roots 4 or more times during a single IDE session. Even then, the IDE would consume 25MB more, which should still not cause any significant problems even with the default max. heap size setting. Although I already have a fix for this issue and will integrate it to the main trunk by the end of this week (after it will be tested by the performance team), I consider this fix too risky to be merged into the release40 branch at this point.
Fixed in trunk (see commits below). There can still be more pages in memory because of the mentioned minicache, which we are not going to remove now, since it will be removed by rewriting the btree to mmapped files. But these pages are now properly gc'ed when the corresponding storage files are unmounted. Checking in src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/FileCache.java; /cvs/mdr/src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/FileCache.java,v <-- FileCache.java new revision: 1.5; previous revision: 1.4 done Checking in src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/IntrusiveList.java; /cvs/mdr/src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/IntrusiveList.java,v <-- IntrusiveList.java new revision: 1.4; previous revision: 1.3 done
Please prepare a fix for 4.0. Thanks.
Fixed in release40. Checking in src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/FileCache.java; /cvs/mdr/src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/FileCache.java,v <-- FileCache.java new revision: 1.3.10.2; previous revision: 1.3.10.1 done Checking in src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/IntrusiveList.java; /cvs/mdr/src/org/netbeans/mdr/persistence/btreeimpl/btreestorage/IntrusiveList.java,v <-- IntrusiveList.java new revision: 1.3.70.1; previous revision: 1.3 done
Verified in release4.0