[squeak-dev] Re: Using #= for integer comparison instead of #==

Andres Valloud avalloud at smalltalk.comcastbiz.net
Wed Dec 1 00:13:00 UTC 2010


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 -
>
>
>
>
>
>



More information about the Squeak-dev mailing list