On Fri, Nov 26, 2010 at 9:15 AM, Andres Valloud <avalloud@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 -