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. 2) There is no "good time" to stop the world in interactive software, because you can't predict when the user-will interact. Client side software needs to maintain sub ~30ms interactivity. Parallel online web-servers for non-trivial services are always running requests, and any stop-the-world pauses all incoming requests. I have heard of systems using cluster load balancing to take GC servers offline before major collections, but this is not very common practice. It is more common to limit per-process heap sizes to minimize pauses. --- So to re-iterate, all x86 GCs I'm aware of except Azul-Zing's "no pause" have a stop-the-world pause during initial-mark of tenured generation which is proportional to heapsize. This includes the "concurrent" collectors for JVM and .NET. Here are some references which review the details. http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html http://msdn.microsoft.com/en-us/library/ee787088.aspx#concurrent_garbage_collection 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. I also think the art of memory management is still usefull with GC .. but > little used , where in C it is often used .. if you test it and create too > many objects reduce it .. eg if you have a non array linked list reuse your > nodes , if you have vertex buffers or buffer[] reuse them . > Absolutely. This is one of the reasons I'm a big proponent of the CLR over the JVM. arrays-of-structs and type-instantiation allow us to more easily use techniques which relieve some of the pressure from the GC. In the JVM we have to resort to stuffing data into opaque buffers to relieve GC pressure. That said, those arrays-of-structs contain pointers, well, then those pointers have to be traced/marked as well. ...which is why I was bringing up the topic of techniques for using non-gc-traced "handles", enabling typesafe manual refcount schemes inside typesafe GC systems -- without adding GC pressure. These techniques can be applied manually in limited scenerios today, but I'm not aware of general purpose and convenient mechanisms to do it. I look forward to the day when we have "no pause" GC in all of our GC runtimes.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
