[concurrency-interest] Garbage First vs a counting collector
Brian S O'Neill
bronee at gmail.com
Thu Mar 26 11:07:37 EDT 2009
How did your collector deal with reference cycles? Was it slow enough to
not be a problem, or did the language prohibit cycles from arising?
Gregg Wonderly wrote:
> One of the things about concurrent programming that bothers me the
> most is latency control. GC activity can often introduce unwanted
> latency by causing arbitrary contention for resources that a thread
> may not be able to recognize as contentious. A long time ago, I
> created a language with a counting collector which I found to be very
> easy to do on a uniprocessor environment. With the advent of CAS, it
> seems at casual grant pretty straight forward to do a counting
> collector on a multi-processor machine.
> The upcomming introduction of the garbage first collector intrigues me
> from the perspective that there is a "ton" of managed resources that
> it uses to make itself smart enough to try and accurately estimate and
> manage the cost of GC activity. There is use of CAS, plus space and
> time based isolation schemes to try and reduce latency that is
> introduced into the application.
> However, it seems to me that there is going to be a new cost
> introduced into every assignment for mutator tracking that might just
> be as expensive as a counting collector is.
> I am not really familiar with the real costs of much of the
> concurrency management instructions, can anyone on the list give me
> some pointers to more information or some insight into whether the
> amount of "tracking" that the garbage first collector will use, is
> still cheaper than a CAS on every reference change to a global object?
> Gregg Wonderly
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest