Re:Google is developing its own Android game console - Report
by pcwalton on Friday June 28, 2013 @03:08AM
(#5956693)
> but, er, browser gc's are not tuned for this purpose at all, so not sure what that tells you.
It seems to me that the goals of browser GC's are essentially the same as those of Dalvik: allow Web pages or phone apps to hit 60 FPS. To this end both SpiderMonkey and V8 have incremental GC's. (They actually have an easier time of things because they don't have to deal with multiple threads sharing a single heap.)
SM shoots for 7 ms for incremental time slices, as I recall, but in practice the major collections can lead to pauses longer than that. Incremental isn't a panacea in practice; in high allocation or high-CPU-load scenarios you either get pauses if you're soft-real-time or you starve the mutator for resources (which can drop the frame rate of the game) if you're hard-real-time. Ironically, decreasing the time slice can sometimes make the pauses worse, because when you're in an IGC slice more stuff is barriered.
> Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage.
Dalvik doesn't use Metronome (or Azul C4, ...). It uses a concurrent GC for minor collections but sometimes has to stop the world for major collections, last I looked (granted, my knowledge is ICS only, so perhaps there have been improvements since then).
(Note that I'm not trying to argue that GC's are bad, or that Dalvik's GC is bad, or that a sufficiently good GC wouldn't be good enough for most games; those are questions that would generate more heat than light to debate. I'm simply pointing out that game developers' concerns about Dalvik's GC are not unfounded or imaginary.)
It seems to me that the goals of browser GC's are essentially the same as those of Dalvik: allow Web pages or phone apps to hit 60 FPS. To this end both SpiderMonkey and V8 have incremental GC's. (They actually have an easier time of things because they don't have to deal with multiple threads sharing a single heap.)
SM shoots for 7 ms for incremental time slices, as I recall, but in practice the major collections can lead to pauses longer than that. Incremental isn't a panacea in practice; in high allocation or high-CPU-load scenarios you either get pauses if you're soft-real-time or you starve the mutator for resources (which can drop the frame rate of the game) if you're hard-real-time. Ironically, decreasing the time slice can sometimes make the pauses worse, because when you're in an IGC slice more stuff is barriered.
> Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage.
Dalvik doesn't use Metronome (or Azul C4, ...). It uses a concurrent GC for minor collections but sometimes has to stop the world for major collections, last I looked (granted, my knowledge is ICS only, so perhaps there have been improvements since then).
(Note that I'm not trying to argue that GC's are bad, or that Dalvik's GC is bad, or that a sufficiently good GC wouldn't be good enough for most games; those are questions that would generate more heat than light to debate. I'm simply pointing out that game developers' concerns about Dalvik's GC are not unfounded or imaginary.)