[bitc-dev] Retrospective Thoughts on BitC
Jonathan S. Shapiro
shap at eros-os.org
Mon Apr 9 18:07:50 PDT 2012
On Mon, Apr 9, 2012 at 5:54 PM, David Jeske <davidj at gmail.com> 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
The STOPLESS collector and the Azul collector were the two I was thinking
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev