On Mon, Oct 14, 2013 at 8:15 AM, david j <[email protected]> wrote: > Actually, I'd like to revise that to two goals, both of which malloc/free > meet... > > 1) minimize pause in non allocating threads > This divides into two parts. The first is that the scheme must avoid any global coordination requirement. We don't want to have to halt all of the mutator threads in order to agree that a GC can start.
The second is to minimize the pause per thread. There are a bunch of systems in which that is essentially a single compare-and-swap or atomic store where the mutator thread acknowledges that a new GC epoch has started. The main complication in such schemes is that the mutator thread may be running a tight inner loop and need to be instantaneously preempted. Finally, I'm not aware of *any* reason that a non-allocating thread should have to pause. The problem is that in most of the safe languages, there is no such beast as a non-allocating thread. This is *part* of why stack allocation and region-based allocation are important things to be looking at. > 2) alloc/dealloc overhead (more) proportional to rate and memory overhead, > not total heap size > Proportional to rate of *what*? I don't think that "proportional" is what you mean to say. If we define the overhead as "100 ms per 100Mbytes allocated", then a system that allocates 10 gigabytes between 10 second pauses meets the specification. And I think it's clear that some data structures can't meet this goal. Specifically: if you produce a lot of cyclic data, you're going to have to pay the piper or give up the safety in current schemes. RC+cycle finding may be able to better minimize these costs than > compacting GC, since some reachability can be determined without a trace. > I concur.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
