"Long monitor contention event" and cache "file not found" warnings/errors

[lele]

Hi, some diagnostic info. Is it normal to have a bunch of these warnings? 

I'm using the persistent cache option in the dev branch. The lag without using the cache was just too much at the moment.

This happens all the times it needs to draw many tiles on screen, not necessarily new. Happens especially when changing zoom levels.

04-10 12:50:04.490  13836-14170/com.example.maps W/art﹕ Long monitor contention event with owner method=java.lang.String java.lang.VMClassLoader.getBootClassPathResource(java.lang.String, int) from VMClassLoader.java:4294967294 waiters=0 for 351ms

04-10 12:50:04.493  13836-14169/com.example.maps W/art﹕ Long monitor contention event with owner method=java.lang.String java.lang.VMClassLoader.getBootClassPathResource(java.lang.String, int) from VMClassLoader.java:4294967294 waiters=4 for 166ms

04-10 12:50:04.495  13836-14171/com.example.maps W/art﹕ Long monitor contention event with owner method=java.lang.String java.lang.VMClassLoader.getBootClassPathResource(java.lang.String, int) from VMClassLoader.java:4294967294 waiters=3 for 196ms

04-10 12:50:04.820  13836-13849/com.example.maps W/art﹕ Suspending all threads took: 8.524ms

04-10 12:50:04.916  13836-13849/com.example.maps W/art﹕ Suspending all threads took: 15.976ms

04-10 12:50:05.140  13836-13844/com.example.maps W/art﹕ Suspending all threads took: 23.664ms

04-10 12:50:05.300  13836-13849/com.example.maps W/art﹕ Suspending all threads took: 10.971ms

04-10 12:50:05.621  13836-13844/com.example.maps W/art﹕ Suspending all threads took: 6.081ms

04-10 12:50:07.691  13836-13849/com.example.maps W/art﹕ Suspending all threads took: 7.011ms

04-10 12:50:08.169  13836-13844/com.example.maps W/art﹕ Suspending all threads took: 49.473ms

04-10 12:50:08.667  13836-13844/com.example.maps W/art﹕ Suspending all threads took: 45.880ms

(any many more)

Also, I get these from time to time. Looks like it thinks there is a tile in the cache but it doesn't find it. This happens sporadically. Some concurrent modification issue or threading issue perhaps?

04-10 12:54:38.430  13836-13859/com.example.maps E/FileSystemTileCache﹕ null

    java.io.FileNotFoundException: /storage/emulated/0/Android/data/com.example.maps/cache/mapcache1/11/980/667.tile: open failed: ENOENT (No such file or directory)

            at libcore.io.IoBridge.open(IoBridge.java:456)

            at java.io.FileInputStream.<init>(FileInputStream.java:76)

            at org.mapsforge.map.layer.cache.FileSystemTileCache.get(FileSystemTileCache.java:265)

            at org.mapsforge.map.layer.cache.TwoLevelTileCache.setWorkingSet(TwoLevelTileCache.java:100)

            at org.mapsforge.map.layer.TileLayer.draw(TileLayer.java:88)

            at org.mapsforge.map.layer.LayerManager.doWork(LayerManager.java:90)

            at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

     Caused by: android.system.ErrnoException: open failed: ENOENT (No such file or directory)

            at libcore.io.Posix.open(Native Method)

            at libcore.io.BlockGuardOs.open(BlockGuardOs.java:186)

            at libcore.io.IoBridge.open(IoBridge.java:442)

            at java.io.FileInputStream.<init>(FileInputStream.java:76)

            at org.mapsforge.map.layer.cache.FileSystemTileCache.get(FileSystemTileCache.java:265)

            at org.mapsforge.map.layer.cache.TwoLevelTileCache.setWorkingSet(TwoLevelTileCache.java:100)

            at org.mapsforge.map.layer.TileLayer.draw(TileLayer.java:88)

            at org.mapsforge.map.layer.LayerManager.doWork(LayerManager.java:90)

            at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

Anything I can do to mitigate the above?

thanks

[Emux]

Dev branch is playing by default with multithreaded rendering.
The default number of threads is one greater than the number of processors, as one thread is likely to be blocked on I/O reading map data.

Try setting MapWorkerPool.NUMBER_OF_THREADS=1 for playing with the old way of 1 thread and see what happens.

My extensive tests indicate currently the multithreaded feature not much usable for production, as it can crash often, usually with OOM depending on Android version and the map content / zoom.

--
Emux
Cruiser - Atlas

[lele]

ok, I tried that and I also tried to revert to 0.5.1 (non-dev). Tried with threads and without and with various queue sizes. Truth is that I didn't see much difference, which I didn't expect.

I also don't fully understand the CPU usage. If I put the queue to 0 or 1 I would expect it to render what's on the screen and then stop. So if I go on a new area the CPU should spike and as soon as the screen is rendered it should go down. It doesn't seem to do that. It seem to go down after a minute or so. What is it doing in that time? I'd like it to avoid spending any CPU time in rendering stuff that is not visible.

Do you see the same behaviour? (I'm using the CPU/RAM monitor on the latest Android Studio as a monitor)

[Emux]

The old feature with threaded cache was strictly for the cache, for writing the tiles in separate thread queue (there was not any multithreaded anywhere).

But we have removed currently that feature (so don't rely too much on that).

[lele]

ok, and what do you think of the CPU traces? Ideally the CPU should go down as soon as the screen is rendered but it doesn't seem to do it

[Emux]

For properly testing, we need the map view alone and preferably outside the context of any complex application.

Note that the map view size is larger than the screen by a factor, in order to paint also some outside area that appears during drag.

We expect the things to settle down after the map rendering and tile caching have completed altogether.

[lele]

Say that you zoom in from zoom level 4 to 13 quite quickly. Is it going to render all the levels or just what you have on the screen?

that would explain why in that case the CPU stays 100% for a couple of minutes even if there is no activity on the map.