#7980 closed defect (fixed)
Out of Heap Memory
Reported by: | pinkduck | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | tested |
Keywords: | Cc: |
Description
I run JOSM stable with the -Xmx768M command line on Windows 7 x64. If I do 14 separate edits, each downloading a different area of OSM data, adding Bing layer, adding StreetView layer, making edits, uploading data and deleting Bing, StreetView and OSM layers to get back to the default window then an Out of Heap Memory exception is given by around the 15th time.
Shouldn't the memory required for use by these layers be freed each time I close them out to get back to the main screen? Or shouldn't the cache of tiles be prevented from exceeding the maximum heap size assigned to the Java run-time instance?
Attachments (0)
Change History (11)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Please note that the stated parameter should have been -XX:+HeapDumpOnOutOfMemoryError in order to enable the heap dump, as the second hyphen-minus means that the option will be turned off in the JVM.
The memory dump after using en-GB JOSM without plug-ins and with the -Xmx512M option can be found at ftp://pinkduck.dyndns.org/ (user name JOSM, blank password) along with RAR and ZIP files of it.
comment:4 by , 12 years ago
Thanks for the heap dump. It turned out there is quite a lot of memory leaks. I've fixed the most simple leaks - leaks that showed up after I created new data layer and removed it. It's possible that it will fix your issue but more likely there is lots of leaks left. So please get latest version of JOSM, keep the HeapDumpOnOutOfMemory parameter on and when you get next OutOfMemory error, upload the dump.
comment:7 by , 12 years ago
Some of our listener collections are non optimal as they keep strong references to the listeners (for example, the selection listeners in DataSet). These collections should use weak references, for example with a CopyOnWriteArrayList<WeakReference<Listener>>, like what is done in Main with projection change listeners.
comment:8 by , 12 years ago
I have encountered another Out of Memory exception in JOSM 5485 after the 28th download/upload/delete-layers edit in a single session. Please see the latest JOSM.hprof and zip/rar in the same FTP location as mentioned before.
Memory should be freed but either in core or one of the plugins can be bug that prevents java from freeing the memory. You can run java with -XX:-HeapDumpOnOutOfMemoryError parameter. That will produce heap dump next time you run into this error. You can upload it somewhere and then one of developers can analyze it to see what's keeping objects in memory.
Note that it's possible to get your osm password from heap dump so please either use OAuth or send the dump privately.