[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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list