Yes, that does make sense.  Thank you :).

On 11/30/10 18:45 , Eliot Miranda wrote:
>
>
> On Tue, Nov 30, 2010 at 6:38 PM, Andres Valloud
> <avalloud at smalltalk.comcastbiz.net
> <mailto:avalloud at smalltalk.comcastbiz.net>> wrote:
>
>     Awesome, thank you!  That makes the "marker technique" more clear.
>       In HPS parlance (excuse me using the terminology I am most
>     familiar with), Squeak has an eden plus two survivor semi spaces,
>     and old space for the rest.  The incremental GC would be a scavenge
>     of new space.  The full GC is a mark / sweep GC of all object data.
>       Does that make sense?
>
>
> Yes.
>
>     Also, would you mind a question?  If the new objects are above the
>     old data, what happens when the old data grows large enough that it
>     runs into the new object space?  Is the new object space moved upwards?
>
>
> Think of the heap (including new space) as one region growing towards a
> limit.  Old space is immediately below new space, a single variable
> pointing to the boundary.  Somewhere above that is the allocation
> pointer.  When one does a tenuring incremental collection new space is
> compacted and the pointer to the top of old space merely set to point to
> teh allocation pointer, so now everything is old. By the same token, to
> do a full gc the old space pointer is merely set to the bottom of the
> heap, so now everything is young, and the roots are the active context
> and the special objects array.
> Unlinke HPS there is no such thing as an old space allocation, because
> there is no free list of free old space objects, and because old space
> and new space are contiguous.  Hence a large allocation will typically
> tenure everything.
>
> Make sense?
>
> best
> Eliot
>
>
>
>     On 11/30/10 16:20 , Andreas Raab wrote:
>
>         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>
>                 <mailto: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 -
>
>
>
>
>
>
>
>
>
>
>         .
>
>
>