I just added a few paragraphs about the various garbage collectors out there in https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:intermediate:optimization#avoid_creating_new_objects .
I took the Android information from How does garbage collection work in Android 4.2 Jelly bean Dalvik VM? - Stack Overflow and garbage collector in android 2.3 - Stack Overflow .
Somebody with interest and knowledge please double-check. I find it important to put that avoid object creation avoidance hint into perspective (since it’s plain inapplicable on the desktop), but I have no experience with Android and might have mistaken something.
1 Like
For android it seems about right, for desktop creating objects i actually not that much of an issue, depending on what and how.
As there are concurrent and g1 collectors. Of course not creating objects is better than creating useless objects.
However don’t do so if it reduced readability and is no proven performance eating point.
Also one should keep in mind that the hotspot jit can do escape analysis and convert heap objects to stack allocations.
1 Like
I suspect escape analysis is limited.
At least it would match the pattern I have seen with other optimizations (inlining, mostly); Hotspot seems to do the usual “do 20% of the coding to get 80% of the effect and don’t bother to cover all corner cases” routine. Which means you have to double-check that any optimization you expect to have is actually applied.
In general, I’d not bother too much about microoptimization on the desktop anyway, Hotspot is doing a good job; algorithmic optimizations are more important.
On Android with its limited resources, microoptimization is really important. It’s good to know that I got that part right.
Just expect a different behavior of runtime environments based on OpenJDK targeting Android, something closer than what you already have in desktop environments, I think about AvianVM (but not RoboVM which is based on Harmony) and the future JogAmp runtime environment (Project Ji Gong) based on OpenJDK 1.8.