On Tue, Nov 30, 2010 at 6:38 PM, Andres Valloud <
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>>  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 -
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> .
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101130/f4ab255e/attachment.htm