On Sun, Oct 20, 2013 at 10:41 PM, Ben Kloosterman <[email protected]> wrote:
> Another point of parralel collectors is most of the pause does not relate > to the nursery sweep I'm concerned that we may have a terminology gap. The way the terms are used in the current literature: *Parallel*: Concurrent collection, concurrent mutation, mutators and collectors do not overlap. *Concurrent*: Mutators and collectors may be concurrent, but halt-the-world pauses may occur. *On-the-fly*: Mutators and collectors may be concurrent, but no halt the world pauses occur. Parallel collectors (by definition) do not overlap mutator and collector, so of course their pause is not just a function of the nursery sweep. Since so much work is going into keeping nurseries thread-local, I'm very surprised that nursery sweeps are being done concurrently. It doesn't make a whole lot of sense. Having gone to all that work to keep the cache traffic strictly within the local L2, The cache-to-cache traffic and the interlocked operations resulting from concurrency almost certainly overwhelm any gain that might be had. Though it is true that the root sweep will tend to drive recycling in the cache. Hmm. *That* might be a reason to maintain a ZCT, now that I think about it. If you are saying that the nursery sweep is fast enough that it does not contribute significantly to pause times, then that would apply to all of these types of collectors. The main difference (in that regard) between concurrent and on-the-fly collectors is that nursery sweeps do not require cross-thread coordination. " The primary *advantage* of on-the-fly is that it allows collection to > proceed during long I/O waits." , > > What about async IO apis (Winrt /aoi) , why would these be blocked ? A > modern standard lib should make these preferrable ( though offer both) > Perhaps. But that's a discussion of I/O architectures, not collectors. Async I/Os don't have long waits, so they aren't relevant to the statement I made. That said, even with async I/O there remain circumstances where the mutator just runs out of stuff to do until the async I/Os complete. If the mutator is data dependent on the I/O, it has to wait. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
