[concurrency-interest] Garbage First vs a counting collector
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?
More information about the Concurrency-interest