On Tue, Jul 16, 2013 at 1:06 AM, David Jeske <[email protected]> wrote:
> On Tue, Jul 16, 2013 at 12:07 AM, Bennie Kloosteman <[email protected]>wrote: > >> Also these types of collectors run much better in the real world where >> there are more low work times then micro benches >> > > At the risk of repeating > myself<http://www.coyotos.org/pipermail/bitc-dev/2012-April/003373.html>-- > this both a myth and a mis-understanding. > > 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. 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. One of the beauties of the sweep phase is that it is completely read-only w.r.t. the mutators, which is why this is possible. The phase that is difficult to manage is the copying phase, because objects are concurrently mutated by the collector and the mutator[s]. This requires, at minimum, some form of coordination and some decision about who shall yield to whom when a conflict arises dynamically. I have certainly seen collectors that behave as badly as you describe. That doesn't mean they have to. > 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. 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. > Client side software needs to maintain sub ~30ms interactivity. > We have hard measurements on this going back to the KeyKOS days and our work on transparent checkpoint. Users notice mouse movement lag at any delay above 10ms. In my opinion, <1ms is required for satisfactory human interaction. > Fishing around to see the current state of Azul Zing, it looks like they > run on unmodified linux now, but they canned their open-source " > managedruntime.org" initiative to open source the technology. Now they > merely offer it free to open-source developers for testing. > Then I guess it's a good thing I captured the change set. :-) Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
