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