Oops gmail from china issues so double posted. Im aware that it still pauses though they claim most of the work is the sweep , in addition marks can be concurrent white black grey etc ,, . And i never said they were pause free ( eg stack scan , gen 0 and gen 1 collect which they claim insignificant - i did not mention mark as i was unsure whethere that part was concurrent) so i hope that wasnt implied. The question is how much they stop - it may be proportional to the # heap refs but if you can reduce it by 90% by taking out the worst cases then its still a lot better..eg that 200ms becomes 20ms ..which combined with other techniques may be enough in many cases..
"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. " Agree.. but what i meant with benchmarks refers to the typical linux micro bench ( and which the people we need to convince use as lot) that runs for 5 minutes flat out on all threads and allows no spare time for concurrent GCs so they collect durring the app repeatedly and not concurrently ( since all threads are busy you are taking a thread from the app) . but in most shops you will run servers at 50-80% CPU , which means there will be spare CPU and hence smaller interference with the app . so concurent GC may perform better in life than in trivial benchmarks . Though uinder peak loads CPU and memory GCs do tend to be worse. Agree completely on ways to remove load from the GCs whether its a manual , ref counted collections , Serializing objects in a cache and reloading when needed ( your opaque buffers) , breaking apps into task with local heap / region pointers or a local GC are all options. Question If you had such a GC like Anzul and im sure given 1M someone can write one and the performance cost is say 30% would you build a runtime or kernel with it ? I could sell it in the java , javascript and C# space and solve the 3D game problem (as 30% more is not a lot ) but i dont think id get many of the Linux C guys On Tue, Jul 16, 2013 at 4:06 PM, 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. > > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
