11

I've found some information about the Android garbage collector that are contradictions to me.

Android Devevelopers Guide says:

Android 3.0 is the first version of the platform designed to run on either single or multicore processor architectures. A variety of changes in the Dalvik VM, Bionic library, and elsewhere add support for symmetric multiprocessing in multicore environments. These optimizations can benefit all applications, even those that are single-threaded. For example, with two active cores, a single-threaded application might still see a performance boost if the Dalvik garbage collector runs on the second core. The system will arrange for this automatically."

Ok, now the other thing

According to this link: The Dalvik Virtual Machine Architecture android uses mark and sweep aproach.

The current strategy in the Dalvik garbage collector is to keep mark bits, or the bits that indicate that a particular object is “reachable” and therefore should not be garbage collected, separate from other heap memory.

If we check how mark and sweep works on this link: Mark and Sweep Garbage Collection Algorithm , we can see this:

The main disadvantage of the mark-and-sweep approach is the fact that that normal program execution is suspended while the garbage collection algorithm runs. In particular, this can be a problem in a program that interacts with a human user or that must satisfy real-time execution constraints. For example, an interactive application that uses mark-and-sweep garbage collection becomes unresponsive periodically.

So my question now is, how does it really work? Does garbage collector pause everything while he is working, or is he capable of running completely independent on the other active processor core?

Drag0
  • 8,438
  • 9
  • 40
  • 52

3 Answers3

11

The Dalvik VM in the Gingerbread and beyond version is using the Mostly Concurrent partial collection garbage collector with pause times usually around 5ms. Therefore, yes, the GC is influencing the other apps by stopping them but the concurrent GC algorithm is able to minimaze these pauses.

You should look at :

In general, the Garbage Collection theory [Garbage Collection Wiki] explains:

  • Stop-the-world garbage collectors completely halt execution of the program to run a collection cycle

  • Incremental and concurrent garbage collectors are designed to reduce this disruption by interleaving their work with activity from the main program. Incremental garbage collectors perform the garbage collection cycle in discrete phases, with program execution permitted between each phase (and sometimes during some phases).

  • Concurrent garbage collectors do not stop program execution at all, except perhaps briefly when the program's execution stack is scanned.
Community
  • 1
  • 1
Aleš
  • 8,896
  • 8
  • 62
  • 107
2

Complete independence is rather impossible: garbage collector and program use the same memory and have to communicate somehow. Even "pauseless" GCs, like Azul's (btw, a good read: http://www.artima.com/lejava/articles/azul_pauseless_gc.html), have technical pauses. Dalvik is probably (pure guess, based on anecdotal evidence and resources likely poured into JVMs during the last 15 years by the likes of IBM, Sun and Oracle) years behind the newest technology found in JVMs, so I suspect that the pauses will be longer.

fdreger
  • 12,264
  • 1
  • 36
  • 42
2

It wouldn't pause other apps, it may pause your app. A mark and sweep doesn't have to stop all processing, its just the easiest way of doing it. It probably has some points where it pauses execution and other where it doesn't. THe only real way to tell would be to look at the Dalvik VM code. And I wouldn't count on it being the same answer in all versions of Android.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127