[concurrency-interest] Garbage First vs a counting collector

Gregg Wonderly gregg at cytetech.com
Wed Mar 25 12:19:27 EDT 2009


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


More information about the Concurrency-interest mailing list