http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/Rowledge-Final.pdf

On pp. 20 it has an excellent summary about how the Squeak GC works.

Cheers,
   - Andreas

On 11/30/2010 4:13 PM, Andres Valloud wrote:
> Yes, from what I've seen, Squeak's GC is different from that in HPS. I
> found some information scattered here and there in Google, but it's
> mostly commentary. Ideally, I'd look at the source code and figure it
> out but I don't quite have the time to look at it in all its detail. I
> would really appreciate a current, 3-5 sentence summary of Squeak's GC
> implementation. Does anyone have such a pointer? I hope this request is
> not deemed ridiculous, I'm thinking it would be just as unreasonable to
> expect anybody to look at HPS' GC implementation and get the gist of
> what's going on in 5-10 minutes. Thanks in advance!
>
> On 11/27/10 14:06 , Eliot Miranda wrote:
>>
>>
>> On Fri, Nov 26, 2010 at 9:15 AM, Andres Valloud
>> <avalloud at smalltalk.comcastbiz.net
>> <mailto:avalloud at smalltalk.comcastbiz.net>> wrote:
>>
>> I'm not familiar with Squeak's GC... can you also assume that a GC
>> (e.g.: a "new space" scavenge) won't move the marker so that the
>> enumeration goes past it?
>>
>>
>> IIUC, that's irrelevant. FOr the marker technique to work all that's
>> needed is that the relative order of live objects isn't changed. The
>> only thing that can change that is a become:. In the absence of a
>> become: the end marker, no matter how many GCs occur, stays above/after
>> all previously activated objects and below/before all subsequently
>> allocated objects. The Squeak GC effectively only compacts to squeeze
>> out reclaimed objects, it does not reorder. So this is very different
>> to the VM/HPS GC.
>>
>> HTH
>> Eliot
>>
>>
>>
>> On 11/26/10 9:12 , Bert Freudenberg wrote:
>>
>>
>> On 26.11.2010, at 18:09, Andres Valloud wrote:
>>
>> Can you assume that allocation is sequential?
>>
>>
>> I can.
>>
>> - Bert -
>>
>> On 11/26/10 8:59 , Bert Freudenberg wrote:
>>
>>
>> On 26.11.2010, at 17:43, Andres Valloud wrote:
>>
>> You *must* use an end marker, i.e.,
>>
>> last := Object new. "end marker"
>> obj := self someObject.
>> [last == obj] whileFalse:[
>> count := count + 1.
>> obj := obj nextObject.
>> ].
>>
>> This will work because it counts between the
>> beginning of memory and the
>> (arbitrary) end marker. Anything else basically
>> should not be relied on
>> to work, jit or no.
>>
>>
>> What happens if a process with higher priority
>> interrupts the iteration and creates more objects?
>>
>>
>> New objects would come after the end marker in memory.
>>
>> - Bert -
>>
>>
>>
>>
>>
>>
>
>