[bitc-dev] Pools in lieu of GC

[Jonathan S. Shapiro]

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.

> 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.

> How do you do GC across many many CPU cores?

There are concurrent collectors.

> As a related question, what's going to be the size of BitC's runtime?

Not yet known. For cases where a simpler collector is sufficient,
probably very small.

> 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
you don't have.