From: Ron Garret
Subject: GC is fast
Date: Sun, 09 Oct 2005 16:13:40 +0000
Message-ID: <rNOSPAMon-57C366.09134009102005@news.gha.chartermi.net>

For those of you who don't read slashdot:

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr
-lnxw01JavaUrbanLegends

The rest of the world is starting to realize that GC can be efficient.

rg

• Re: GC is fast Rob D.
  • Re: GC is fast Ulrich Hobelmann

From: Rob D.
Subject: Re: GC is fast
Date: Mon, 10 Oct 2005 07:26:12 +0000
Message-ID: <4f6ac$434a5daa$18609aeb$26078@KNOLOGY.NET>

Ron Garret wrote:
> For those of you who don't read slashdot:
> 
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr
> -lnxw01JavaUrbanLegends
> 
> The rest of the world is starting to realize that GC can be efficient.
> 
> rg

I read through a bunch of the comments for the story (the
first time it was posted, anyway), and someone mentioned this
paper:

     http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf.


Just another data point, I guess.  Their conclusion was
interesting.  They claim that with five times as much memory
to play with, garbage collection can meet or exceed the
performance of explicit management, but with less memory than
that, garbage collection performs much worse.

-- 
Rob D.

From: Ulrich Hobelmann
Subject: Re: GC is fast
Date: Mon, 10 Oct 2005 13:37:00 +0000
Message-ID: <3qv93sFgk89sU1@individual.net>

Rob D. wrote:
> Ron Garret wrote:
>> For those of you who don't read slashdot:
>>
>> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr
>> -lnxw01JavaUrbanLegends
>>
>> The rest of the world is starting to realize that GC can be efficient.
>>
>> rg
> 
> I read through a bunch of the comments for the story (the
> first time it was posted, anyway), and someone mentioned this
> paper:
> 
>     http://www.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf.

Interesting, but it should be mentioned that applications are also 
written differently in a GCed language (or rather functional-oid 
language), probably creating more short-lived garbage for the 
generational GC.  Measuring that is much harder...

> Just another data point, I guess.  Their conclusion was
> interesting.  They claim that with five times as much memory
> to play with, garbage collection can meet or exceed the
> performance of explicit management, but with less memory than
> that, garbage collection performs much worse.

As long as it's fast enough:
http://rifers.org/blogs/gbevin/2005/4/8/myth_java_cant_scale_down
(as was also posted in that /. discussion)

-- 
State, the new religion from the friendly guys who brought you fascism.