id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
16734	JOSM stuck in event loop for multiple seconds	stephankn	team	"JOSM is stuck in the event loop for multiple seconds. See the attached YourKit profiler snapshop and the long events report in the threads tab. For size reasons only the last block of 8s has call stacks.

I can reproduce this by panning to a fresh area, then waiting a while (I suspect 300s to remove threads). When I then change the Zoom level and Pan, then the GUI is frozen for quite long.

I suspect this is more significant as I have a large map window on a 4K screen and due to a fast internet connection configured max 12 concurrent tasks per host, 64 total. Increasing the total max might make it worse.

If I get the stack right, we are inside the painting loop in
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.drawInViewArea(Graphics2D, MapView, ProjectionBounds) AbstractTileSourceLayer.java:1514

What is the reason that here tiles are loaded and not simply painted? If tiles are available, they can be painted. If tiles are due to be loaded this is something to expected to take longer, so why not offloading this to a later point in time?

Or maybe it was intended to do so? The (before mentioned) JCSCachedTileLoaderJob.submit() might do this. But according to the profiler this method then takes away 71% of the time in the painting loop. In my case multiple seconds.

Later on a lot of time is spent here:
HostLimitQueue.java:143 <...> java.util.concurrent.ThreadPoolExecutor.setCorePoolSize(int)

which seems to be part of a ""trick"" to exploit a side effect of the method. Looks like this was implemented by wiktorn. 

I believe when the block happens I see a lot of thread creations and destructions happen in a short time. Doing this synchronous in the painting loop seems to cause the delay.


The following snippet os a call stack of what I believe a single call.


{{{
""Name"",""Level""
""AWT-EventQueue-0  Runnable CPU usage on sample: 234ms"",""1""
""java.util.concurrent.ThreadPoolExecutor.setCorePoolSize(int)"",""2""
""org.openstreetmap.josm.data.cache.HostLimitQueue.offer(Runnable) HostLimitQueue.java:143"",""2""
""org.openstreetmap.josm.data.cache.HostLimitQueue.offer(Object) HostLimitQueue.java:30"",""2""
""java.util.concurrent.ThreadPoolExecutor.execute(Runnable)"",""2""
""org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.submit(ICachedLoaderListener, boolean) JCSCachedTileLoaderJob.java:168"",""2""
""org.openstreetmap.josm.data.imagery.TMSCachedTileLoaderJob.submit(boolean) TMSCachedTileLoaderJob.java:150"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.loadTile(Tile, boolean) AbstractTileSourceLayer.java:891"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.access$100(AbstractTileSourceLayer, Tile, boolean) AbstractTileSourceLayer.java:141"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSet.loadAllTiles(boolean) AbstractTileSourceLayer.java:1272"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSet.access$1000(AbstractTileSourceLayer$TileSet, boolean) AbstractTileSourceLayer.java:1183"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.drawInViewArea(Graphics2D, MapView, ProjectionBounds) AbstractTileSourceLayer.java:1514"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.access$2700(AbstractTileSourceLayer, Graphics2D, MapView, ProjectionBounds) AbstractTileSourceLayer.java:141"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSourcePainter.doPaint(MapViewGraphics) AbstractTileSourceLayer.java:1892"",""2""
""org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSourcePainter.paint(MapViewGraphics) AbstractTileSourceLayer.java:1886"",""2""
""org.openstreetmap.josm.gui.MapView.paintLayer(Layer, Graphics2D) MapView.java:468"",""2""
""org.openstreetmap.josm.gui.MapView.drawMapContent(Graphics2D) MapView.java:583"",""2""
""org.openstreetmap.josm.gui.MapView.paint(Graphics) MapView.java:490"",""2""
""java.awt.EventDispatchThread.run()"",""2""


}}}


by removing ""HostLimitQueue.offer()"" and setting executor.setCorePoolSize(maximumPoolSize) in setExecutor it improved significantly, but I am quite confident this is no solution to this issue, just a hint to confirm the hypothesis that the dynamic thread handling blocks.
"	defect	closed	normal	18.09	Core imagery	latest	fixed	cache performance	wiktorn