[concurrency-interest] Garbage First vs a counting collector

Gregg Wonderly gregg at cytetech.com
Thu Mar 26 19:03:55 EDT 2009

Boehm, Hans wrote:
> [Little to do with concurrency, but ...]
>> Yes, in my implementation, I was using the malloc libraries 
>> and just allowing them to internally manage grouping.  My 
>> collector had nothing to deal with compaction or otherwise 
>> manage fragmentation.
>> In particular there are very real issues where small amounts 
>> of memory are used and freed frequently with just as many 
>> larger chunks of memory being allocated more permanently.  
>> String concatenation from loops like
>> 	InputStream rd = ...
>> 	int i;
>> 	byte buf[] = ...
>> 	String str = "";
>> 	while( ( i = rd.read(buf) ) > 0 ) {
>> 		str += new String( buf, 0, i );
>> 	}
>> are great at creating small free structures intermingled with 
>> larger permanent structures which can quickly fragment memory 
>> into unusable segments.
>> Compaction is something that is vital to long lived highly 
>> dynamic application.
> This really depends on the underlying allocator (malloc) implementation.

Compaction can occur as either an implicit or explicit strategy in the overall 
management of allocations.  Your paper illustrates one way to manage the type of 
issue that my example would create with the original malloc() allocator that C 
started with.  That didn't last long, and pools of fixed size did become visible 
quite a long time ago, in the '80s as I recall.

It's great to see all the continued research and work on trying to make GC 
really not be an impediment to latency estimates in software design.

Gregg Wonderly

More information about the Concurrency-interest mailing list