On Thu, Feb 3, 2011 at 9:35 PM, Ben Kloosterman <[email protected]> wrote: It was mentioned earlier that the standard library may not use copies that may be non atomic due to the GC.. I should have asked this at the time but is there a point ? Can you make a GC compaction or move and not stop the world without a scheme that is incredibly costly ? For a start you must stop the threads to scan the stack... The problem isn't limited to libraries. The best work on this, as I've mentioned in the past, is the work be Steensgaard, though his work does not consider unboxed unions. The limit on incrementalism is that a given object has either been copied or it has not. In a lock-free concurrent collector, the approach is to contrive to notice when the object has changed and abandon (or retry) the copy when this occurs. Provided the upper bound on object size is small enough, this eventually converges, though the argument about it is tricky. 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. Not only is it not incredibly costly; it works quite nicely. But also: the metric of "costly" needs to be examined. In a time when additional cores are idle and unusable, bounding in-band wait and establishing a floor (i.e. a guarantee) on GC progress may be much more important than maximizing GC performance. Which is why GC tuning remains a black art... 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) ... There will be some large mutable code eg scientific problems and 3D but it should be very rare in BitcC and could be moved to its own process with a custom GC config ( eg ref counting may do if the desire is to avoid pauses or even all static data) while most apps use a fast nursery with fast access. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
