OK. Some of litmus test questions here concerning pause times: 1. It is it acceptable if a low-and-slow background collector takes an exclusive lock on an object long enough to trace that object? While this lock is held, mutators attempting to *write* to this object will block.
I can unfortunately imagine various sorts of dynamic "box car" kinds of outcomes in which a single mutator thread might have the misfortune to queue up behind a bunch of these in sequence. The scenario here is when the collector is clearing a logged object out of the log. It needs to hold a lock long enough to implement the increments. 2. In a concurrent collector scenario, there are cases where interference between collector threads needs to be avoided, and this is best done with a lock bit. There are also cases where a mutator may choose to act temporarily as a collector (e.g. while GCing thread-local allocations). The maximum duration of such an interlock should be the time to scan the object, potentially performing one compare-and-swap for each reference therein. Is this an acceptable delay? When might it *not* be an acceptable delay? 3. Can we tolerate a requirement that an object must be held under a write lock in order to be modified when there are concurrent mutators? This reduces the potential contention between mutators and collectors to a * single* mutator, which is a great simplification. 4. Some of these overheads can be reduced or moved around if we document certain fields as atomic. An "atomic" field is one that should always be updated by atomic operations. In particular, such a field is *not* managed by logging and deferred update. An object lock is not required to modify an atomic field. Is it tolerable to require that such fields be identified as part of their declarations?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
