On Wed, Mar 4, 2009 at 5:58 PM, Eric Rannaud <[email protected]> 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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
