On Mon, Apr 9, 2012 at 5:54 PM, David Jeske <[email protected]> wrote:
> I am unaware of a so-named "concurrent" collector which does not have an > unacceptable stop-the-world pause of the old-generation (I believe for > initial-mark). Certainly those in modern Java and C# have unacceptable and > unpredictable worst-case pause times. The only research I'm aware of which > attempts to solve this problem is Microsoft STOPLESS, > CHICKEN<http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf>, > and hardware-assisted Pauseless > GC<http://static.usenix.org/events/vee05/full_papers/p46-click.pdf>by Azul. > None of these are available in generally useful x86 > implementations. > The STOPLESS collector and the Azul collector were the two I was thinking about. > In real systems we expect to be able to respond to user-actions 10-20ms. > This is not possible to do reliably with today's GC systems. > I think that overstates the requirement in some cases and grossly * understates* it in others - in audio applications, the proper target is 0.7ms to 1ms for certain inputs. But it is generally my experience that programs with truly hard requirements of this kind have phases in which they apply and phases in which they do not. If that is true, then the real problem is less the cost of GC than the inability to write GC-free subprograms. What seems to have happened is that the safe programming world, having bought off on the idea that GC was an inevitable requirement, then declared that no other form of memory handling was interesting. This, of course, was an issue that BitC was trying to address explicitly. > This is simply impossible in a GC system which *unpredictably* stops the > world. This in turn makes stop-the-world GC impossible to use for many > systems. > I don't like stop-the-world collectors either, but that "unpredictably" word in your sentence is critical. The only collectors I know of that are really unpredictable in this way are collectors for concurrent programs that require a universal thread rendezvous. > We simply have to stop stopping the world. > That *really* needs to go in your signature. :-) > It's all too easy to dismiss these pauses as insignificant, but in real > situations in real systems, we are avoiding GC everyday because of this > issue. It must be fixed for GC-based systems to replace C-shlibs. > I hope you don't feel that I was dismissing them. I tend to agree with you, though I do think that a language along the lines of what BitC was doing probably offers a range of exploitable middle positions. Certainly doesn't solve the problem entirely, but maybe enough for a lot more applications to be able to make the jump to safe runtimes. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
