<br><br><div class="gmail_quote">On Wed, Mar 4, 2009 at 4:40 PM, Jonathan S. Shapiro <span dir="ltr"><<a href="mailto:shap@eros-os.com">shap@eros-os.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There is one case where assessing heap allocation is straightforward:<br>
the case where you don't do any.<br>
<br>
The pools concept has been tried in other languages. The necessary<br>
region analysis, done conservatively, is not that difficult. The<br>
problem is that it *is* done conservatively, and there are cases that<br>
are pathologically bad. For this reason, pools do not replace GC<br>
effectively for many programs.<br>
<br>
> There are situations where a garbage collector is not desirable...<br>
<br>
I can name some, but they are *very* special cases, and nearly all of<br>
them are cases where a "zero allocations" policy is appropriate. The<br>
other extreme is cases where GC effectively becomes disk GC by virtue<br>
of paging, but that one is manageable by using an appropriately<br>
specialized runtime, and it is rare.<br>
<br>
I would be very interested to know which situations *you* have in<br>
mind, and *why* GC is inappropriate for those situation.<br>
<div class="im"></div></blockquote><div><br><br>I'm, for one, am thinking about using BitC to write virtual machines. <br>On this case, using just a GC is pretty complex, as it would require a meta-circular<br>design, which brings a lot of trouble on itself as can be witnessed on the few VMs that<br>
have such design.<br><br>At the same time, there is no reason for a GC written in BitC to require the use of big chunks<br>of unsafe code just because it has to deal with low level memory management - as, obviously,<br>it can't use another GC for this job.<br>
<br>There are some issues with been GC only for memory allocation. Generating code that is good for<br>precise GC is tricky, either you make a performance compromise or you generate huge stack maps;<br>object placement is another issue, as some objects used by the GC itself can't be moved. On the<br>
end of the day, a VM will have to replace the BitC runtime provided collector with one that bends well<br>with the target runtime.<br><br>On the other hand, with a placement allocation syntax whichs allows the use of application controlled<br>
regions/pool and given that those can come from malloc'd/mmap'd, I think BitC would be a great fit for<br>writing a GC.<br><br>Rodrigo<br></div></div>