[bitc-dev] Pools in lieu of GC

Eric Rannaud eric.rannaud at gmail.com
Wed Mar 4 19:18:07 EST 2009


On Wed, Mar 04, 2009 at 06:36:38PM -0500, Jonathan S. Shapiro wrote:
> On Wed, Mar 4, 2009 at 5:58 PM, Eric Rannaud <eric.rannaud at gmail.com> wrote:
> > (I'm not sure I really understand in what practical situations a GC
> > would be forced upon the user, so it may not be a real problem in the
> > following contexts. If avoiding the GC just means not escaping closures...
> 
> The two are unrelated. If you allocated on the heap, you will eventually GC.

Why would you allocate a closure on the heap? And even it's that the
case, if it's not escaping, you can just free it when it gets out of
scope. Why do you need to GC? Sorry, I don't understand what you're
saying here.


> > What about embedded application on platforms with just a few hundred KB
> > of RAM (no disk or secondary storage)?
> 
> This situation is *ideal* for GC.
> 
> > What about hard real-time applications?
> 
> Define "hard real time". Most of the things that people believe to be
> hard real time are not. Many of the rest have non-real-time phases. So
> this question can only be answered sensibly with a but more
> refinement.

This is always a good question to ask somebody who thinks he needs
hard-RT, as many situations are not as bad as they sound. But from the
point of view of language design, unless you're claiming there are no
hard-RT situations out there, or that BitC will just not work for them,
I fail to see the pertinence.


> > How do you do GC across many many CPU cores?
> 
> There are concurrent collectors.

Yet few are used on any kind of real-life large scale (I don't know of
any). Are you damn sure that this will never present a challenge?

How do you implement a GC on CUDA? What about an hypothetical 1000 cores
CPU? It may well not be impossible, but is the research on this advanced
enough, and the implementation numerous and well understood enough that
the question can just be set aside?

What about real-time (say, bounded worst-case latency) *and* concurrent
collectors? I mean, this can get hairy, don't you think?


> > Can we expect a notion similar to freestanding environments as in C?
> > (similar in its resource requirements)
> 
> Probably not. The Coyotos kernel will simply not include the
> collector, but it's a special case. Pragmatically, if your memory is
> so tight that you can't afford the space for a collector, you can't
> afford to write in assembler and you can't afford to use the heap that

I guess you mean "you can't afford not to write in assembler"? If so, I
disagree. I've written embedded applications using a few dozen KB of RAM
in C, and that's just fine. And a lot easier that in assembly. You have
to be careful about inlining and stack size but that's far from
unreasonable constraints.


> you don't have.

What do you need a heap for?

Thanks.


More information about the bitc-dev mailing list