Memory leak in "Show Status Report" after opening a big *.osm file

[rickmastfan67]

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2011-07-26 01:31:22
Last Changed Author: bastiK
Revision: 4264
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2011-07-25 12:24:22 +0200 (Mon, 25 Jul 2011)
Last Changed Rev: 4264

Identification: JOSM/1.5 (4264 en)
Memory Usage: 154 MB / 3640 MB (123 MB allocated, but free)
Java version: 1.6.0_26, Sun Microsystems Inc., Java HotSpot(TM) 64-Bit Server VM
Operating system: Windows 7

NOTE: This is done with no plugins installed.

Steps to reproduce:

1. Start up an instance of JOSM with no plugins installed. [ Memory Usage: 154 MB / 3640 MB (119 MB allocated, but free) ]
2. Load a large *.osm file (~115MB)
3. Load the "Show Status Report" [ Memory Usage: 1293 MB / 3640 MB (569 MB allocated, but free) ]
4. Close it and reopen "Show Status Report" [ Memory Usage: 1490 MB / 3640 MB (182 MB allocated, but free) ]
5. Repeat step 4. [ Memory Usage: 1590 MB / 3640 MB (554 MB allocated, but free) ]
6. Repeat step 4. [ Memory Usage: 1648 MB / 3640 MB (310 MB allocated, but free) ]

I would attach the *.osm file that I've done this with, but I can't compress it smaller than 6.26MB and you guys have a 2MB attachment limit.

Also, every time I go to open the "Show Status Report" when I have open said file, it takes at least 8 seconds for it to load and on average, uses about 19% of my CPU (6 core processor). In comparison, I can open the "About" menu almost instantly.

I've also noticed that in Windows, when I start JOSM by directly opening the *.jar file, memory usage stays low (must be something built directly into javaw.exe if a jar file is manually triggered). However, when I run trigger JOSM via the following shortcut: "C:\Program Files\Java\jre6\bin\java.exe" -Xmx4096M -jar josm-tested.jar (can even substitute java.exe with javaw.exe), my memory problems above still happen.

Any ideas why this would be happening?

[xeen]

Opening the status dialog takes so long because data consistency tests are performed. By default (i.e. double clicking the jar file) a lower value is set on -Xmx which is likely the reason for lower memory consumption (-Xmx4096m tells Java it may use up to 4 GB of RAM). Can you try to alter the shortcut to, say -Xmx1024M, and repeat your steps to see if the JVM is only too lazy to run garbage collection or if it an actual leak?

[bastiK]

You can't detect memory leak from that, you need memory usage right after garbage collection. The tool jconsole can be used to monitor memory usage and trigger gc manually.

[rickmastfan67]

Well, I've changed it to -Xmx1024m and here are the results: (all plugins disabled; r4390)

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2011-09-01 01:31:33
Last Changed Author: simon04
Revision: 4390
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2011-08-31 21:41:56 +0200 (Wed, 31 Aug 2011)
Last Changed Rev: 4390

Identification: JOSM/1.5 (4390 en)
Memory Usage: 122 MB / 910 MB (95 MB allocated, but free)
Java version: 1.6.0_27, Sun Microsystems Inc., Java HotSpot(TM) 64-Bit Server VM
Operating system: Windows 7

1. Memory Usage: 122 MB / 910 MB (95 MB allocated, but free)

< File opened >

2. Memory Usage: 531 MB / 910 MB (169 MB allocated, but free)
3. Memory Usage: 545 MB / 910 MB (220 MB allocated, but free)
4. Memory Usage: 549 MB / 910 MB (288 MB allocated, but free)
5. Memory Usage: 555 MB / 910 MB (281 MB allocated, but free)
6. Memory Usage: 606 MB / 910 MB (216 MB allocated, but free)
7. Memory Usage: 595 MB / 910 MB (227 MB allocated, but free)
8. Memory Usage: 608 MB / 910 MB (345 MB allocated, but free)
9. Memory Usage: 604 MB / 910 MB (265 MB allocated, but free)
10. Memory Usage: 612 MB / 910 MB (272 MB allocated, but free)

While doing this, java.exe was almost constantly using around 18% of my 6-core CPU. And whenever I closed the "Show Status Report", it took FOREVER to reopen again to get the next memory usage total. If anything, can JOSM be enhanced to run the "data consistency tests" faster when you have more CPU cores available to you?