On Tue, Jul 16, 2013 at 12:30 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 1) When they say "concurrent" they mean "concurrent sweep". The intial >> mark still requires stop-the-world, and it is still proportional to >> live-pointer-count (or as Jonathan more precisely said, cachline loads >> caused by gc-mark). In other words, so called "concurrent" collectors still >> pause (stop the world), they are *not* pause-free -- they just pause. less. >> > > So first, this is *not* true of the C4 collector. > Yes of course. My words were specifically in response to comments about the ".NET concurrent collector"... equallly true of the "JVM Concurrent collector". When .NET and JVM say "concurrent" today, they mean "concurrent sweep". > And second, this is *not* true of any intelligently structured > large-space sweep. It is entirely possible - and in fact straightforward - > to implement a fully incremental and concurrent sweep phase on old space. > This is one of the motivations for so-called Card Tables. > The sweep is easy to make concurrent (as .NET and JVM do). The pause comes from stop-the-world mark of the large tenured generation... as is explained in the links I posted for both .NET and JVM. 2) There is no "good time" to stop the world in interactive software, >> because you can't predict when the user-will interact. >> > > I agree that there is no good time. User interaction, in my mind, isn't > the driving concern. We definitely know how to build GC systems that have a > worst-case upper pause bound under 1ms subject to reasonably generous > assumptions about allocation rate. Of course that won't be good enough for > all cases, but it's good enough for most. > ...it's only good enough for small heaps, or large heaps with small percentages of pointer-polluted cachelines. Mono is being used quite a bit as part of Unity framework for mobile games, so that's one case where small heapsizes end up viable for GC. Large heap desktop software, or large-heap backend-web-services are not fairing so well. They are still written in C/C++. My metric for this is driven by interrupt response. My goal is therefore a > maximum *single mutator thread* pause time in the sub-100 microsecond > range. If that can be achieved, I think we can all agree that the > interactive problem is effectively solved. > Yes, we agree if we never pause any thread for more than 100 microseconds, the interactive problem is solved. (assuming reasonable other tradeoffs in doing so, like CPU and memory overhead) We need to get that capability into the default royalty free version of a major language runtime (.NET, JVM).... Sign me up for that!! -- (I want to add (V8), but I think their apartment model threads would be too limiting even with no-world-stop.)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
