Repeated changing of an editor kit over a single editor pane leads to memory leak of both NbEditorDocument and also DocumentView and accompanied view factories etc.
It can be reproduced by repeated invocations of search bar by Ctrl+F - each invocation goes through SearchComboBoxEditor.changeToOneLineEditorPane() calling
It used to manifest by unremoved FoldHierachyListener in FoldViewFactory but Svata fixed it by #246590 so now the reference is held by BracesMatchHighlighting. I will search for a way to possibly have an API/SPI for this.
The HighlightsContainer should be notified about no longer being used (when HighlightingManager.rebuildAllLayers() is called and the original layers are thrown away. IMO we could create UnistallableHighlightsContainer interface to extend HighlightsContainer with "void uninstalled()" method in it.
Created attachment 155774 [details]
Fix of the problem that adds a ReleasableHighlightsContainer
Fixing of the problem requires adding of ReleasableHighlightsContainer interface that any HighlightsContainer may implement to be notified once a HighlightingManager stops using the particular layer.
Asking for fasttrack review since the ReleasableHighlightsContainer is added to Highlighting SPI.
Increased module's spec version and added apichanges item and a test.
A quick query shows 41 implementations of HighlightsContainer, and 4 more in contrib.
R01 - Do they all need to implement the new ReleasableHighlightsContainer?
R02 - Should we log a warning for HighlightsContainers, not implementing ReleasableHighlightsContainer?
Ralph, thank you for the comments.
> A quick query shows 41 implementations of HighlightsContainer, and 4 more in
> R01 - Do they all need to implement the new ReleasableHighlightsContainer?
No, it's just an optional interface for the case when the particular highlights container wishes to be notified about releasing. If it does not implement it it just continues to work the same way as before.
> R02 - Should we log a warning for HighlightsContainers, not implementing
No, IMHO many highlights containers can work fine even without implementing it - they e.g. already use weak listeners etc. Unfortunately in the case of BracesMatchHighlighting it would not be sufficient (as soon as it register highlight into MasterMatcher the memory leak will happen) so I have implemented this approach.
Integrated into 'main-silver', will be available in build *201509030002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Miloslav Metelka <email@example.com>
Log: #254701 - Memory leak upon repeated calls of JEditorPane.setEditorKit() on a single pane.