On Android, Garbage Collection Can Kill You(war-worlds.com)
war-worlds.com
On Android, Garbage Collection Can Kill You
http://www.war-worlds.com/blog/2012/06/on-android-garbage-collection-can-kill-you
37 comments
FTA: "A quick look at the output from ddms shows I was allocating tens of thousands of Colour, Vector2 and Vector3 objects per image"
And this is the fault of the garbage collector? Doing per-primitive ops by allocating heap blocks is a disaster, sorry. No one doing HPC does that. This won't run well anywhere, though obviously a desktop machine is going to give you a lot more freedom before you see frame rate problems.
And this is the fault of the garbage collector? Doing per-primitive ops by allocating heap blocks is a disaster, sorry. No one doing HPC does that. This won't run well anywhere, though obviously a desktop machine is going to give you a lot more freedom before you see frame rate problems.
It's the fault of the garbage collector because the JVM provides no sane alternative (like, say, structs, or packed object arrays...).
If there's Only One Way To Do It, that One Way should not cause the garbage collector to fall over and choke. It sounds like the desktop JVM handles it just fine, in comparison.
If there's Only One Way To Do It, that One Way should not cause the garbage collector to fall over and choke. It sounds like the desktop JVM handles it just fine, in comparison.
Why not just pre-allocate the objects and reuse them?
This is what I do for Android games -- design things to be mutable and pre-allocate however many I'll need during a level. You also have to avoid foreach because it creates objects.
This is an area where C# is better. You can create classes or structs and structs go on the stack. Structs are a lot more appropriate for objects like rects.
This is an area where C# is better. You can create classes or structs and structs go on the stack. Structs are a lot more appropriate for objects like rects.
Have fun getting that pattern right by hand. The language isn't doing anything to help you.
Make sure you release the instances back to the pool on every exit path, but don't release them if you let a reference escape into another scope.
Have fun debugging the issues that crop up when you accidentally release an instance that's still being used back into the pool.
Have fun hunting down that one code path that isn't returning instances to the pool, and as a result is draining the pool down to 0 and causing you to gain nothing from it.
Make sure you release the instances back to the pool on every exit path, but don't release them if you let a reference escape into another scope.
Have fun debugging the issues that crop up when you accidentally release an instance that's still being used back into the pool.
Have fun hunting down that one code path that isn't returning instances to the pool, and as a result is draining the pool down to 0 and causing you to gain nothing from it.
Didn't people do all that before the advent of GC? People seemed to manage resources just fine.
In garbage collected languages you really need to keep track of how much garbage you create. I've seen too many examples of people creating objects they really don't need in loops when they could recycle a single one for the entire procedure.
On Google App Engine, Over Quota can kill you:
Over Quota This application is temporarily over its serving quota. Please try again later.
is all I get right now from the link.
Over Quota This application is temporarily over its serving quota. Please try again later.
is all I get right now from the link.
It's ironic that we need to use Google to cache a Google site that's over-quota, right?
Actually, Dalvik's GC just plain sucks, too.
Clojure has a similar problem: works fine on desktop JVMs, but even initialising it takes many seconds on Dalvik.
Clojure has a similar problem: works fine on desktop JVMs, but even initialising it takes many seconds on Dalvik.
It's been a while since I looked at the Clojure source, but from what I recall, the initialization problem is almost wholly related to loading all of clojure.core, not garbage collection.
If you're hitting slowdowns after initialization, there's a good chance it's reflection, not garbage collection. Type hinting can help if that is the case.
Because of the way that Clojure reuses immutable data structures, it doesn't do as much garbage collection as one might think.
If you're hitting slowdowns after initialization, there's a good chance it's reflection, not garbage collection. Type hinting can help if that is the case.
Because of the way that Clojure reuses immutable data structures, it doesn't do as much garbage collection as one might think.
Your laptop has 10x memory bandwidth of top-end Android phones (and 20x of midrange phones). Double the numbers for desktop.
In short, mobile devices are different than laptops/desktops. If you threat them same, your application will suck.
In short, mobile devices are different than laptops/desktops. If you threat them same, your application will suck.
Closer to 5x than 10x. Don't do the math based on the clock speed, look at the cycle times (which are mostly the same between DDR3 2000 and LPDDR2 533). A desktop or laptop CPU (unless by "laptop" you mean "netbook" -- laptops based on mainstream CPU cores have the same memory interconnect as desktops) will have two 64 bit DRAM channels, a typical phone will have a single 32 bit channel.
I use completely different threats for mobile devices, laptops, and desktops.
If you don't stop misbehaving and start running my code correctly I'll ((forget to take you out of my pants pocket on laundry day)|(see just how far that hinge will bend)|(take you to the landfill))
None of these work BTW.
Edit: Sorry
If you don't stop misbehaving and start running my code correctly I'll ((forget to take you out of my pants pocket on laundry day)|(see just how far that hinge will bend)|(take you to the landfill))
None of these work BTW.
Edit: Sorry
Works without problems in Scala. Maybe Clojure isn't using the available resources efficiently enough?
Maybe the Scala examples you think of indulge in quite a bit of destructive updates?
Functional programming style tends to generate lots and lots of objects which die very young. Garbage collectors must be tuned for that. At least they should be generational. Mayhaps Dalvik's current GC is not?
Functional programming style tends to generate lots and lots of objects which die very young. Garbage collectors must be tuned for that. At least they should be generational. Mayhaps Dalvik's current GC is not?
Aye, seems Dalvik's GC is a pretty simple mark-and-sweep.
> Functional programming style tends to generate lots and lots of objects which die very young.
Well, there is a lot of Scala code out there doing exactly that.
HotSpot has no problems with short-lived objects in pretty much all its garbage collectors while Dalvik's GC is just a lot less sophisticated and mature.
So I mainly agree with you, but the proposition of
Well, there is a lot of Scala code out there doing exactly that.
HotSpot has no problems with short-lived objects in pretty much all its garbage collectors while Dalvik's GC is just a lot less sophisticated and mature.
So I mainly agree with you, but the proposition of
Language allows producing lots of short-lived objects
+ Dalvik sucks
------------
Programs in that language have to be slow
> Well, there is a lot of Scala code out there doing exactly that.
I talked about specific examples that I don't even know of. I don't know Scala enough to know whether non-destructive updates are the default. Are they? What about the core libraries?
I agree your proposition in fixed width font does not hold. I was merely asserting this one:
I talked about specific examples that I don't even know of. I don't know Scala enough to know whether non-destructive updates are the default. Are they? What about the core libraries?
I agree your proposition in fixed width font does not hold. I was merely asserting this one:
Program P produces lots of short-lived objects
+ Dalvik sucks (or is tuned for long lived-objects)
-------------------------------------------------
Program P have to be slowClojure still generates a lot more garbage, especially during bootstrap. This can be seen easily with VisualVM on the desktop, comparing hello world in the two languages.
Scala generates a lot less garbage, by construction. A lot of that has to do with its compilation model, which is a lot closer to Java's than Clojure's is.
Clojure just assumes the JVM can deal with it, and desktop ones do just fine, hence why no one noticed.
Clojure just assumes the JVM can deal with it, and desktop ones do just fine, hence why no one noticed.
I guess from the headline, I expected more than what everyone already knows: garbage collection takes up processor time, especially on unoptimized code. I was expecting something new.
Ah yes, but the article claims that Dalvik has a poor gc.
Is this really a credible complaint? Someone who wrote this:
public int hashCode() {
return new Double(x).hashCode() ^ new Double(y).hashCode();
}
You beat me to this issue. When I read this code I cringed, because it's so naïve it's like reading something intentionally pessimized, such as "if(new String("true").equals(new Boolean(b).toString()){...}" instead of "if(b){...}".
Can you explain what is obviously wrong in this code?
You don't need to allocate a new double to call hashCode on it. You can just call hashCode on the double you already have.
Out of curiosity, what language background are you coming from that this isn't obvious?
Out of curiosity, what language background are you coming from that this isn't obvious?
[deleted]
It's a bit strange to me that one of the recommended optimizations is to create fewer objects in a programming language that is heavily object oriented.
I remember the last time I got involved in one of these discussions, where the same give-and-take was brought up: https://groups.google.com/d/msg/comp.lang.ruby/vWcRBbg8VGE/0...
It's not GC per se, it's that the Dalvik JVM doesn't do some analysis and note that the object that you create to pass to a method which doesn't escape it can be created on the stack as it is guaranteed not to exist beyond the calling method.
Synchrony issues occur when sharing an object pool among multiple threads. If you're sharing an object pool and using an unsafe data structure you will run into concurrent modification exceptions. Another issue could also be that using a thread safe data structure (or more simply a syncrhonized method) will lead to huge performance degradations because it is a central point of contention. A third issue with object pools is that if you have multiple threads using an object pool it might fill up your entire heap with cached objects.
The lifecycle issues come into play when you ask the question, "Who returns the object to the pool?" For example you could have 1 thread passing an object to another thread and then returning the object to the pool. If not considered you could run into a possibility where 2 different threads are operating on an object as if they are the sole owners leading to unexpected results.