On Mon, Jul 15, 2013 at 10:39 AM, Jonathan S. Shapiro <[email protected]>wrote:
> ...allocation is not a good predictor of tracing pressure. Tracing > pressure is most directly a function of *reachability* rather than a > function of the number of allocations. More precisely: allocations trigger > collections, but the cost of collection is a function of liveness. > Yes, exactly. Generational schemes, regions, liner-types attempt to solve problems with connected or short-lived garbage. However, handling random discards in long-lived objects still has a cost proportional to reachability in any known mark/sweep/copying GC. For long running programs, with large heaps, that have modest amounts of long-lived churn, this reachability scanning cost is much much higher than manual-strategices, malloc, free, ARC. This is separate from the issue of pausing and latency. I submit that "no pause" (**) collectors like the production JVM Azul/Zing or research chicken/stopless (should they ever become practical) can/should achieve wost-case pause/latencies comparable to C/C++. In fact, they might even be lower. However, Azul/Zing is MMU supported and needs kernel support that is not (yet) available in mainstream operating systems. (**) I prefer the term "no pause", meaning "no stop the world"... to the term "concurrent", since all the shipping "concurrent" collectors I'm aware of have stop-the-world pauses proportional to heapsize. ---- The net-net of all that is if we wish to find a typesafe compromise which has an attractive performance profile relative to C/C++ for large/interesting heapsizes, we are going to be using some amount of ARC which is hidden from the reachability process.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
