On 1/11/2014 6:18 PM, Colin Putney wrote:
>
>
>
> On Sat, Jan 11, 2014 at 5:12 PM, Florin Mateoc <florin.mateoc at gmail.com <mailto:florin.mateoc at gmail.com>> wrote:
>
>     On 1/11/2014 4:26 PM, Colin Putney wrote:
>
>  
>
>     It does not skip over the sentinel. It encounters the "end" earlier because you create a new object after the
>     sentinel was created.
>     If you do Object new nextObject you get 0. So when the proxy is materialized and then gets sent nextObject it
>     returns 0
>
>
> This is what I mean. We start enumerating objects with nil, walk through memory until we hit the proxy, jump forward
> in memory to the materialized ancestry object, and continue until we hit 0. That jump causes a bunch of objects to be
> skipped, including the sentinel. 
>
> It still doesn't explain why we get to the end of memory. MCProxyInfo faults in its target by reading MC versions into
> the image from a repository, then searching their ancestries for the object it represents. The object it becomes is
> virtually guaranteed not to be the most recent object allocated. So #nextObject will answer some object, and we'll
> execute the block at least once more. That should send us into the infinite loop that the sentinel object is designed
> to prevent. 
>

No, by following the proxy's nextObject, we start iterating a different loop than the original one (constituted by the
bunch of objects just created, the proxy being the oldest in the bunch) until we reach the newest one among them, which
will return 0.
The sentinel is there because, even if only one block activation is created, we do not want to include it in the
iteration, otherwise a check for 0 would be good enough.
If you open code the loop (say [(next := next nextObject) ~= 0] whileTrue: [...loop body...]) there is no block
activation, so a check for 0 would be enough (if we don't otherwise create new objects).

Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140111/a0e7f6b5/attachment.htm