On Fri, Nov 26, 2010 at 9:15 AM, Andres Valloud <
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/20101127/a4439e3c/attachment.htm