Memory Leaks

[GerdP]

What steps will reproduce the problem?

1. Ctrl+N : Open new data layer
2. Alt+Shift+V: Make sure Validator Panel is visible
3. Draw a way without adding tags
4. Upload (a popup shows that you have a way without tags)
5. Press continue
6. Press cancel in the following dialog
7. Close all layers to get back to the "Getting Started" dialog
8. Repeat steps 1-7
9. Create heap dump with e.g. VisualVM and look at instances of ValidatorTreePanel

What is the expected result?

No or maybe 1 instance

What happens instead?

2 instances

Please provide any additional information below. Attach a screenshot if possible.

Working on a patch...

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-12-31 15:09:58 +0100 (Mon, 31 Dec 2018)
Build-Date:2018-12-31 14:24:10
Revision:14620
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14620 de) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 707 MB / 1820 MB (560 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080

Plugins:
+ OpeningHoursEditor (34535)
+ apache-commons (34506)
+ buildings_tools (34807)
+ download_along (34503)
+ ejml (34389)
+ geotools (34513)
+ jaxb (34506)
+ jts (34524)
+ o5m (34405)
+ opendata (34805)
+ pbf (34576)
+ poly (34546)
+ reltoolbox (34788)
+ reverter (34552)
+ utilsplugin2 (34793)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.
- W: Region [TMS_BLOCK_v2] Resetting cache
- W: Cannot start IPv4 remotecontrol https server on port 8112: Keystore was tampered with, or password was incorrect
- W: Cannot start IPv6 remotecontrol https server on port 8112: Keystore was tampered with, or password was incorrect

[GerdP]

In 14672/josm:

fix #17184: fix leaks in ValidateUploadHook and ValidatorTreePanel.destroy()

[GerdP]

I've now learned that I have to watch the mouse cursor position when doing my tests. I see very different results in the heap dumps depending on the panels that the mouse cursor was in. So, some of the leaks which I found in #17040 still exist, esp. those in the preferences dialog. Many elements of that dialog are only freed when a new Preference Dialog is created, so they are never reused but kept for as long as JOSM runs. Still trying to find the cause...

[GerdP]

Attached patch is work in progress. Maybe not all changes are needed.

[GerdP]

This patch seems to make it more likely that the add tag dialog "forgets" the keyboard. When I edit with this patch I often see
cases where the OK button is enabled but pressing enter has no effect.

[skyper]

Replying to GerdP:

This patch seems to make it more likely that the add tag dialog "forgets" the keyboard. When I edit with this patch I often see
cases where the OK button is enabled but pressing enter has no effect.

I notice the lost of focus almost all the time with dialogs like "download data" and "add tag". Have to recheck but think that #5280 and #13497 were not completely fixed.

[GerdP]

In 17418/josm:

see #17184: Memory leaks

• remove listener when layer is removed (regression of r13608)

[GerdP]

In 17420/josm:

see #17184: Memory leaks

• don't keep list of OSM data in validator tests (not a real problem, but makes it harder to find real leaks)

[GerdP]

In 17421/josm:

see #17184: Memory leaks

• reset field lastUsedNode in draw mode (not a real problem, but makes it harder to find real leaks)

[GerdP]

In 17422/josm:

see #17184: Memory leaks

• reset selection in selectRelationAction (not a real problem, but makes it harder to find real leaks)

[GerdP]

In 35673/osm:

see #17184: Memory Leaks

• clear references to command instances or OSM objects to ease finding of real memory leaks

[GerdP]

In 17439/josm:

see #17184: Memory leaks

• implement method clear() in GpxData and call it when the GpxLayer is destroyed

Reduces memory leak when GPX layers are merged. Without this change GC seems to be unable to free the memory for WayPoints

[GerdP]

In 17440/josm:

see #17184: Memory leaks

• remove more listeners in destroy()
• reset fields which might reference OSM objects
• call data.clearSelection when data layer is destroyed so that fewer actions keep references on OSM elements in that layer

My goal here: When a layer is closed JOSM should really allow to GC all OSM data and GPX data that was loaded before.

[GerdP]

In 35682/osm:

see #17184: Memory Leaks

• don't keep dialog in MultiTagAction, it is newly created each time when the shortcut is pressed
• overwrite setVisible to clear tableModel in MultiTagDialog so that it doesn't keep refs to OSM objects
• simplify code (sonar issues)

[GerdP]

In 17455/josm:

see #17184: Memory leaks

• don't keep ref to primitives, it isn't needed anywhere

[GerdP]

In 17458/josm:

see #17184: Memory leaks

• clear collection rememberMovements in OrthogonalizeAction when no edit layer exits
• clear refs to layers which may disturb GC, maybe because of the complex cyclic deps

[GerdP]

In 17461/josm:

see #17184: Memory leaks

• clear refs to OSM objects when Extrude Mode is ended

[GerdP]

In 17462/josm:

see #17184: Memory leaks

• clear refs to OSM objects in popup memu of PropertiesDialog

[GerdP]

In 17464/josm:

see #17184: Memory leaks

• clear also refs to Conflicts which refer to OSM data in DataSet

[GerdP]

In 17471/josm:

see #17184: Memory leaks

• use String.intern() for field role in RelationMemberData constructor.
• clear HistoryDataSet when last HistoryBrowserDialog instance is closed

We have route relations with +1000 members and +1000 versions. It's probably not a good idea to create all the RelationMemberData instances in advance. Will open a separate ticket for that.

[GerdP]

In 17473/josm:

see #17184: Memory leaks

• clear also virtual ways when exiting SelectMode

[GerdP]

Seems I made some progress here. My last few edit sessions didn't show any leak regarding GPX data or OSM data (after upload and closing all layers). I only used buildings_tools and utilsplugin2 and of course lots of core actions/modes, so that doesn't mean much ;)

[Don-vip]

In 18008/josm:

fix #21105 - see #17184 - make sure that most operations of GpxLayer are harmless after call to destroy()