[concurrency-interest] Garbage First vs a counting collector

Joe Bowbeer joe.bowbeer at gmail.com
Wed Mar 25 16:29:45 EDT 2009

Can you point us to a good reference on the G1 you are referring to?  (Not a
handset, I assume.)

On Wed, Mar 25, 2009 at 11:32 AM, Jeremy Manson wrote:

> 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.
> Jeremy
> On Wed, Mar 25, 2009 at 9:19 AM, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090325/826fb99d/attachment.html>

More information about the Concurrency-interest mailing list