[bitc-dev] Pools in lieu of GC

[Rodrigo Kumpera]

On Wed, Mar 4, 2009 at 4:40 PM, Jonathan S. Shapiro <shap at eros-os.com>wrote:

> There is one case where assessing heap allocation is straightforward:
> the case where you don't do any.
>
> The pools concept has been tried in other languages. The necessary
> region analysis, done conservatively, is not that difficult. The
> problem is that it *is* done conservatively, and there are cases that
> are pathologically bad. For this reason, pools do not replace GC
> effectively for many programs.
>
> > There are situations where a garbage collector is not desirable...
>
> I can name some, but they are *very* special cases, and nearly all of
> them are cases where a "zero allocations" policy is appropriate. The
> other extreme is cases where GC effectively becomes disk GC by virtue
> of paging, but that one is manageable by using an appropriately
> specialized runtime, and it is rare.
>
> I would be very interested to know which situations *you* have in
> mind, and *why* GC is inappropriate for those situation.
>


I'm, for one, am thinking about using BitC to write virtual machines.
On this case, using just a GC is pretty complex, as it would require a
meta-circular
design, which brings a lot of trouble on itself as can be witnessed on the
few VMs that
have such design.

At the same time, there is no reason for a GC written in BitC to require the
use of big chunks
of unsafe code just because it has to deal with low level memory management
- as, obviously,
it can't use another GC for this job.

There are some issues with been GC only for memory allocation. Generating
code that is good for
precise GC is tricky, either you make a performance compromise or you
generate huge stack maps;
object placement is another issue, as some objects used by the GC itself
can't be moved. On the
end of the day, a VM will have to replace the BitC runtime provided
collector with one that bends well
with the target runtime.

On the other hand, with a placement allocation syntax whichs allows the use
of application controlled
regions/pool and given that those can come from malloc'd/mmap'd, I think
BitC would be a great fit for
writing a GC.

Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20090305/566a01a9/attachment.html