Hello Michael,
On 10.09.2018 22:07, Michael Zangl wrote:
Tile loading should be in background. You can completely ignore those
loader threads and need to focus on the AWT Event Thread instead. This
is the thread that should not be blocked. It can be blocked by several
things, e.g.:
* Synchronisation (waiting e.g. for a tile thread)
* Graphics rendering (filters / ...)
* Stop-the-world garbage collection
Thanks. This is also my understanding. I try to figure out where it
blocks. With it being reproducible quite easy I hope to be able to
contribute a meaningful analysis of the problem.
I just started with YourKit, but I worked with similar tools before. So
hoping I get similar results from that one.
The AWT Eventqueue looks a bit generic. YourKit can point to "Long AWT
Events" in the "Threads" tab. I have for example one longer than 5s.
What I not yet understand is, why the marked red bar of the event
duration stretches much longer than the section where it prints a
stack-trace.
It looks to be here:
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer$TileSet.visitTiles(Consumer,
Consumer) AbstractTileSourceLayer.java:1293
which is:
public void visitTiles(Consumer<Tile> visitor,
Consumer<TilePosition> missed) {
tilePositions().parallel().forEach(tp ->
visitTilePosition(visitor, tp, missed));
}
So it seems to be something with tile handling, which would be
consistent to my assumption that it has something to do with tile loading.
I not yet fully understand the timeline view of the profiler here.
It lists two sections, one with "Sample duration" 900ms and one with
5.200ms.
Are the ForkJoinPool.commonPool threads the one doing the parallel work?
Most of them are blocked on synchronized (paintMutex) in
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.lambda$paintTileImages$2(List,
Object, Graphics2D, Tile) AbstractTileSourceLayer.java:1027
What I not understand is when looking at the one in the pool working, it
is drawing a tile:
org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.drawImageInside(Graphics2D,
BufferedImage, TileAnchor, TileAnchor, Shape)
AbstractTileSourceLayer.java:993
But I don't see that one consuming massive CPU. Think I have to re-check
how to better record the profiler logs. Maybe sampling faster?
Is there any specific class or behavior you could point to with this
(limited) level of information to further check?
Thanks,
Stephan
