[bitc-dev] Pools in lieu of GC
Jonathan S. Shapiro
shap at eros-os.com
Wed Mar 4 18:36:38 EST 2009
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
> 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.
More information about the bitc-dev