[concurrency-interest] Garbage First vs a counting collector

Jeremy Manson jeremy.manson at gmail.com
Wed Mar 25 14:32:56 EDT 2009

I'm not a G1 expert, but I'm not sure why it wouldn't be?  As I
understand it, there are three cases:

1) In the case where you are doing an assignment in the same region,
G1's barrier is only a few bit-twiddling instructions and an
if-statement that checks which region you are writing.

2) In the case where you are writing to a region you've already
written, it is 1) plus a memory read and another condition to check if
you have already written to the region.

3) In the case where you are writing to a region you haven't already
written, it is 2) plus a memory write to record the fact that you are
writing to another region.

4) Once in a great while, there is some maintenance to organize the
list of regions you have written.

Even 3) is orders of magnitude cheaper than a CAS.  I'm not sure how
expensive 4) is, but it doesn't happen all that often.

Also, proof by politics: If G1 were as expensive as a CAS on every
write, no one would even be thinking about using it.


On Wed, Mar 25, 2009 at 9:19 AM, Gregg Wonderly <gregg at cytetech.com> 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