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.
I've found that if you perform multiple searches the ResultModel objects and the associated ResultRootNode and FoundNode objects all get retained in memory. Not only does this chew up memory, but it also impacts performance because all the FoundNode objects continue to listen on the data objects. I found this in 3.5, and the patch is for 3.5. I don't see any change in ResultModel in 3.6, but ResultViewTopComponent is gone so the behaviour may be different in 3.6 but I'd guess its still there. The fix works by removing the references from ResultRootNode to the FoundNode objects (via the Children) and by making the FoundNodes only be weakly referenced by the data objects. Unfortunately, I still find that the ResultModel/ResultRootNode/FoundNode objects for the last search executed remain in memory. That is until another search is executed. Couldn't work out a nice clean way to resolve that. Looks messy since it happens via ResultViewTopComponent having a reference to the explorer manager which references the result root node via its explored and root context. Anyway, I hope that a variant of this patch will make it into 3.6. It'd be nice if 3.6 didn't gradually slow down and consume more and more memory like all previous releases.
Created attachment 13657 [details] patch to ResultModel
Created attachment 13658 [details] patch to ResultViewTopComponent
I will not apply the patch in the current form - it causes that search results are lost when the Search Results window is closed, which is undesirable. I appreciate your help with investigation of pending links to objects. It seems that the cause of the memory leak is that property change listener(s) are not unregestered.
I agree. IMHO the close() method on the model should be called in setModel() of the ResultView component, not in componentClosed(). I am currently building sources with the patch. I will let you know how it works...
Created attachment 13666 [details] A patch for NB36 (trunk).
Marian, please review my patch. Profiler shows me that the resources are now cleaned correctly. I started after searching filesystems for "er" substring with 13570kB and after many searches (looking for "a", "e", "i", "o", ..., and at the end again for "er") with 13575 kB. And the number of TextDetail class instances, which used to grow and grow and grow, is now stable. Let me know, if you agree with the patch, and I will integrate it. THX.
Yes, the patch looks good. You may integrate it. Thank you.
Fix integrated in trunk. Brett, thanks for pointing this out and suggesting a fix!
There is no problem to search repeatedly in build 200402261900. Verified.
reopen to fix status and resolution
fix status and resolution