[bitc-dev] Retrospective Thoughts on BitC

Jonathan S. Shapiro shap at eros-os.org
Tue Apr 10 10:09:17 PDT 2012

On Tue, Apr 10, 2012 at 3:11 AM, David Jeske <davidj at gmail.com> wrote:

> On Apr 9, 2012 6:08 PM, "Jonathan S. Shapiro" <shap at eros-os.org> wrote:
> > 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.
> My experience is less forgiving.
> Consider any reasonably large GUI application -- a word-processor,
> computer game, or a 3d graphics modeling program. There is no acceptable
> time to stop the world because one can't predict when the user will
> interact next. Moving most of the data out of the view of the GC is a
> solution, but then we're right back to non-safety....

So I agree that the behavior you describe exists, but I do *not* agree that
it is any sort of impediment to use. The occasional, rare, 20ms pause in an
application like this just isn't a big deal

> The same lack of forgiveness is present in threaded web applications.
> There is normally no time that all threads are simultaneously in a pausable
> activity.
A general stop isn't actually required. What's required is for all threads
to enter a new allocation regime before the GC can start. So basically,
you're complaining that the existing GCs are excessively naive and
therefore aren't meeting your needs. Where concurrent programs are
concerned, I tend to agree.

So what should we *do* about it?

> > 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.
> I confess to being fully in the GC camp. I'm there not through foregone
> conclusion, but through decades of watching the safe/unsafe tradeoffs in
> manual/refcounting/gc techniques.
But that's *exactly* the false dichotomy that the PL world lives in. You
assume that the only alternative is manual memory management. The thing is:
you are mistaken. There are two other, very useful, alternatives:

   1. Language support for unboxing, which reduces the number of heap
   allocations and permits stack allocation
   2. First-class regions, which permit swathes of objects to be eliminated

 I see no way to write 'real' apps (a game, word processor dom, web browser
> dom, 3d modeler, caching webserver) without heap mutability, and no way to
> provide typesafe heap mutability without GC.
But the argument here isn't about removing GC. It's about combining GC with
other *safe* techniques so that (a) the load on the GC is reduced, and (b)
the triggering of GC can be predicted, and (c) the triggering of major
collections can be avoided

> In the absense of that, I'm very happy with the direction of the CIL
> design (relative to JVM or those before it) because value-type-structs and
> parametric-type-instantiation off us practical ways to reduce tracable
> pointers and thus pressure on the GC.
Yes and no. The value types in CIL remain second class, the absence of a
fixed-length array type is crippling to some very important cases, and the
atomicity rules in the presence of concurrency defeat a whole bunch of
inlining options.

> > 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.
> I do not understand the significance of your observation. AFAIK, every
> currently shipping software collector, for every language system, requires
> an unpredictable world-stop. If I am mis-informed, please point me to one
> that does not.
As far as I know, there are *no* shipping collectors whose GC trigger
conditions are unpredictable. In every case, GC is an optional side effect
of allocation. The conclusion, then, is that we need the ability to
construct allocation-free subprograms.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120410/064cc721/attachment.html 

More information about the bitc-dev mailing list