Ok, I discovered that these GC messages were caused by a repaint() in a timer in my code. If I comment the repaint() out I don’t get these messages in a loop, so this was misguiding.
But I still have strange issues: each repaint() calls in my app generates GC_FOR_ALLOC and GC_CONCURRENT messages, but also mouse events:
Each time I press a component in my app, when mouseDown gets called, these messages appears (and the app slows down). What is really strange is that I still get these messages even if the mouseDown implementation is empty! I really don’t get it, but I’ll try to make a minimal app to locate the problem more precisely.
If your apps are running faster on older, single-core devices, bear in mind with newer, multi-core devices you could be having thread-affinity problems. Android could be scheduling the next timeslice of your code to run on a core that is powered down, for example.
[quote=“0xDEADBEEF”]If your apps are running faster on older, single-core devices, bear in mind with newer, multi-core devices you could be having thread-affinity problems. Android could be scheduling the next timeslice of your code to run on a core that is powered down, for example.
Interesting read, but here there’s no particular threading involved as it’s reproducible with just a minimal GUI; except maybe some threading Juce could use internally (repaint ?), I don’t know.
I’m not sure if this is the case, it was just a thought. Even if the paint() method is on a single thread, between invocations it could be context switched out to allow another processes thread to run on the powered-up core and then context switched in again on a different core that is spun-down at the time. If one can test to set the affinity of the GUI thread to a certain core and this ameliorates the problem, then at least one would know where to start looking. Of course it is likely nothing to do with this as the kernel scheduler should just work™
Now I have working Juce apps on all android devices, yay! the downside being to be only android 3.0 and later compatible…
Btw, I just noticed that on the android developer website:
[quote]Don’t create render objects in draw methods
A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.[/quote]
This could be one of the reason why the paint methods in Juce triggers all these GC messages.
Sorry about reviving an ancient thread, but the problem still exists in 2020, and the link you shared is broken now, do you still remember how you solved the problem?