On Tue, Feb 8, 2011 at 3:58 AM, Ben Kloosterman <[email protected]> wrote:
> > > I personally don't really believe in this approach. I think a better model > is to imagine that there *is* a lock between the mutator and the GC, but > that we want to establish a bound on the duration of this lock by limiting > the number of words that the lock covers. We can then view the lock-free > implementation as an optimistic optimization. > > > > I would think the main argument against these is a potential race condition > around the object state necessitating a CAS ( or worse on some > architectures) as well as the cost of checking the object state on reads.. > You seem to indicate that the check is only needed on a copy but what about > all the threads and other objects that reference it ? There may be some way > of tracking these references and ensuring they are not accessed but it seems > expensive to me. > Yes. That is why it is merely an optimization. > True but on a large amount of cores you can just move the code to new > processes instead of threads meaning the pauses become a non issue ( due to > the smaller memory) ... > That simply isn't true. An arbitrarily large number of threads can become blocked on the GC of a large object. More cores doesn't help. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
