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.
Repeating CVS Update action on the same VCS FS shows a significant increase in memory usage. Memory meter shows the following heap usage numbers for updates on checked out nb_all/core module. after start of the IDE (VCS FS already mounted and checked out) - 13,1 MB after 1st update action - 15,5 MB after 2nd update action - 17,9 MB after 3rd update action - 20,2 MB This means roughly 2,4MB memory leak per one update action on a filesystem size of nb_all/core module. Profiler indicates that (among others) the increased consumption is caused by instances of o.n.m.vcscore.cache.CacheReference, o.n.m.vcscore.caching.VcsCacheFile$VcsPersistentData, java.io.File (referenced by the objects above), javax.swing.text.GapContent$MarkData, javax.swing.text.GapContent$StickyPosition, javax.swing.text.AbstractDocument$LeafElement ...
Created attachment 14282 [details] Snapshot of jprofiler window after 2nd CVS update
Created attachment 14283 [details] Snapshot of jprofiler window after 3rd CVS update
The same leak appears when you do Refresh Recursively on the checked out nb_all/core module. The size and structure of the leak is the same, vcs cache being the obvious culprit.
It's a surprise for me that the number of CacheReference instances grows. These are created as references for AbstractFileObjects and old unused objects should be garbage-collected. Perhaps the fact that they are SoftReference cause some problem? Scheduling for promotion D. The mechanism of the leak has to be investigated and we need to prevent it in the cache redesign (issue #32089).
First scan. There is one obvious bug that SoftReference subclass holds some data (File and cache Id). These behave as hardreferenced.
It seems to me that CacheReference.getCacheFile() and CacheReference.getCacheName() are never called so associated fields could be removed. File is quite big object as it holds absolute path.
SoftReferences itself cannot be the problem because it's manifested by repeating the refresh operation over the same data. So there is no need to create new references, old unreleased should be reused.
CacheReference leak eliminated. CacheHandler.java new revision: 1.18 Checker, please note that Runtime -> VCS Commands can keep huge amount of history. For 3x nb_all/core recursive updates it's about 12MB. But it's not leak by itself because setting limit to 0 (default 20) releases this memory.