Subj : Re: Memory reordering problem (or is it?)
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Fri Jun 17 2005 03:30 pm

Joe Seigh wrote:

> Giancarlo Niccolai wrote:
>> Joe Seigh wrote:
>> 
>> 
>>>Giancarlo Niccolai wrote:
> ...
>>>>
>>>>More can be found at: http://www.memorymanagement.org/
>>>>
>>>
>>>I don't think any of them will be as efficient as RCU or SMR.  Some of
>>>those GC algorithms seem to have horrific overhead that make SMR even
>>>with its full
>>>memory barriers look efficient.   They seem to have this attitude that it
>>>is
>>>important to GC *everything* no matter what the cost.  The only one that
>>>comes nearest is distributed reference counting where they just scan the
>>>thread
>>>stacks and refcount the heap.  The problem with that is the only place
>>>it's safe to examine the stack is from the thread itself which has some
>>>problems.
>>>
>> 
>> 
>> More MODERN approaches (and generally, but not always, more efficient
>> ones) uses heuristic strategies (i.e. generational approaches) to
>> determine where the garbage is most likely to be, or i.e. partial
>> reference counting to provide the GC with an hint on what is more likely
>> to need collections. This all is explained at the pointer I gave; here I
>> just explained the very basic set of the very basic techniques used in
>> the field...
>> 
>> What is clear today is that probably there isn't the "perfect" collector,
>> and any collecting strategy that has been developed up to date has at
>> least one area of application in which it outperforms the others... or
>> even in the case that it is less efficient (algoritmically) than others,
>> where it is more "suited" to "do the job".
>> 
> That link points to "everything" in that general area of GC.  I'm not
> about to go read every single paper written on GC when I have a pretty
> good idea what the issues are and when those techniques don't really apply
> to the kinds
> of situations I'm interested in.   The situations I'm interested in are
> the kinds JSR-166 was created to address since the GC in Java won't handle
> them efficiently no matter what GC implementation you put into Java.
> 

Uhm, I never suggested you to read everything. I was explaining the general
situation to  a person that need to get a general idea before digging
deeply into what he specifically needs (which wasn't you)...

Oh, and btw, you are right about the Java GC...

GN.

.