12

Both Windows Phone/Xbox and Android lack support for generational garbage collection. This is frustrating for a lot of programmers. There seems to be a legitimate engineering reason to it, but I can't figure it out.

Current phones have more memory and probably better CPUs than the desktops/laptops running .NET 1.1 with generational GC back in 2001, and I can't think of any reasons that ARM processors would be worse at generational GC than x86 would. There's also less need for multitasking on phones and consoles, so there's relatively more free heap space.

So what gives?

Edit: A few points to clarify:

  • These platforms use garbage collection for apps exclusively, so my question isn't about why GC isn't supported; my question is about why generational garbage collection isn't.
  • The reason that people are frustrated about the lack of generational GC is that non-genrational GC is extremely inefficient. (That means that battery life isn't the reason.)
  • I do believe that there's an honest technical reason for the lack of generational GC support. This isn't a rhetorical question.
2
  • Windows phone (the current generation) does have garbage collection. It only runs when the device is low on memory msdn.microsoft.com/en-us/library/gg490770.aspx Feb 8, 2012 at 0:17
  • @TomSquires The GC on WP7 runs once every 1MB of allocations, actually. I think you might be thinking about the task manager kerning old processes. Feb 8, 2012 at 0:23

4 Answers 4

5

I think the biggest problem is the battery life. Garbage collection is a developer convenience bought at the price of additional CPU cycles on user's computer. When your CPU is plugged in (desktop) or has a relatively large battery (laptop), your users are more willing to pay for developers' convenience with the additional energy consumed by CPU while doing garbage collection. When the battery is relatively small, the users may not be as generous. They may want that additional bar for themselves - perhaps to talk to their friends, or to kill a few extra pigs in a deadly encounter with angry birds.

No matter what users' reasons are, OS developers do not want to form a perception that the devices running their OS drain battery faster than ones running their competitor's OS. So they buy better perception of their devices' expected battery life time at the price of developers' convenience: to them, your pain is no big deal, as long as the users are happy with the devices.

7
  • 3
    Generational GC is much more efficient in most cases, actually, so you'd think that it'd reduce the number of clock cycles. It also doesn't explain why something like Xbox doesn't have generational GC, because Xboxes are plugged in. Feb 7, 2012 at 23:03
  • Well, that's what I heard on Stack Overflow. I do not know much about XBox-es, though. Feb 7, 2012 at 23:09
  • 3
    That still doesn't answer the question. Even if garbage collection used more power than explicit allocation (which is highly debatable -- and I won't get into it), the question isn't if/why explicit allocation is better than GC on mobile, it's if/why non-generational GC is better than generational GC on mobile. Feb 7, 2012 at 23:17
  • 1
    @Rei: Games typically require everything to be deterministic; at least, they need predictable performance. A few nanoseconds wasted here and a few nanoseconds wasted there - at unpredictable times - can screw up a game experience. Generational garbage collectors are unpredictable.
    – Ant
    Feb 7, 2012 at 23:17
  • 2
    @djacobson I don't think that's true. Like I said in the question, if it were just Microsoft's platforms neglecting generational GC, then it'd probably just be a logistical/bureaucratic reason, and I wouldn't bother asking. But Android suffers the same problem too, so it's likely a technical reason, which means that someone on P.SE might have a definitive answer. Feb 7, 2012 at 23:45
3

My best guess would be that it's not a technical reason, but that the developers for those phone platforms simply haven't put in the effort yet. I know it's not the answer you're hoping for, but if you've done any mobile development you've probably noticed there is a lot of low hanging fruit. They probably simply haven't had the time to write multiple GC implementations, fine tune them all, and select the one that does best. Why would anyone spend time reinventing the wheel when they could instead release new, flashy, poorly-thought-out APIs? ;)

FWIW, and as confirmation of my theory, Android's new runtime (ART) does have a generational GC and they're planning to have a compacting GC in the future.

0
2

There is some additional cost to generational garbage collection.

The generational collector needs to be able to find out when older objects point to newer objects. We can't trace through the older object to find these cases because that would defeat the purpose of generational collection. Instead, we somehow need to detect when this happens and make note of it for the collection phase. Regardless of how you are going to do that, it'll add some overhead to the collection process.

On a desktop system, your operating system is busily doing all kinds of things with memory behind the scenes. It supports features like sharing pages between processes, writing unused pages to disk, providing memory mapping between processes, etc. My understanding is that some of the functionality used there makes it possible to more efficiently track pointers being changed. The operation is already worrying about what you are changing in memory, so using that information for new purposes isn't a problem.

I suspect that mobile systems aren't doing all the same stuff behind the scenes. As a result, they don't have the same level of information that a desktop would have. In consequence, the overhead involved in implementing a general collection is higher and less likely to be worth it.

1
  • Taking maximal advantage of GC generations requires the use of write fences to detect when older-generation objects are written. On the other hand, even if the "mark" portion of the GC couldn't benefit from generations, I would think one could still improve performance by only moving things in newer generations (actually, doing the "tag" phase on older generations as well as newer could be useful if it allowed one to know how much reclaimable memory existed in each generation).
    – supercat
    Jul 10, 2012 at 19:11
0

Old question, but it merits a present-day (2020) answer.

Generational garbage collection arrived for Android ART in Lollipop 5.1, but (AFAIK) only in Nexus/Pixel ROMs. I think Marshmallow/6 was the version when "regular" Android devices (Samsung, LG, etc) started using it.

AFAIK, all Nougat/7 devices supported generational garbage collection with stock Nougat/7 ROMs.

Generational GC went away in Oreo, and was still missing from Pie.

It supposedly returned with Android 10(Q)... but I'm not sure whether ALL Android 10 devices with stock Android 10 ROMs have generational GC again, or only Pixel devices, with "other" (Samsung, LG, etc) devices having to wait until Android 11 to finally get it back. I don't presently own a device capable of running 10, so I can't confirm it firsthand.

I can't find documented proof of it, but I'm pretty sure Android's historical lack of generational garbage-collection was entirely due to one or more patents Oracle inherited from Sun. It wouldn't surprise me if that's also why generational GC was taken away for two years (Oreo and Pie)... their lawyers probably stumbled over one last patent that would have ensnared them if they combined generational GC with concurrent GC.

2
  • 1
    Weird. I wonder how the patent might have affected Android and Windows Phone but not Windows or OSX/*nix? Jun 11, 2020 at 7:55
  • @ReiMiyasaka Because of contracts between Sun and Google, not just patents. Well, MacOS got rid of garbage collection, and iOS never used it. MacOS started with reference counting and switched to automatic reference counting, iOS always used ARC..
    – gnasher729
    Jun 11, 2020 at 8:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.