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.
| Summary: | Memory leak upon repeated calls of JEditorPane.setEditorKit() on a single pane | ||
|---|---|---|---|
| Product: | editor | Reporter: | Miloslav Metelka <mmetelka> |
| Component: | Painting & Printing | Assignee: | apireviews <apireviews> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | API_REVIEW, API_REVIEW_FAST |
| Priority: | P2 | ||
| Version: | 8.1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 239360 | ||
| Attachments: | Fix of the problem that adds a ReleasableHighlightsContainer | ||
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 > contrib. > > 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 > ReleasableHighlightsContainer? 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) Changeset: http://hg.netbeans.org/main-silver/rev/ea9c1e6864a7 User: Miloslav Metelka <mmetelka@netbeans.org> Log: #254701 - Memory leak upon repeated calls of JEditorPane.setEditorKit() on a single pane. |
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 editorPane.setEditorKit(kit); at SearchComboBoxEditor:163 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.