On Sat, Jan 11, 2014 at 5:12 PM, Florin Mateoc <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.

My guess is that Cog (and any StackVM?) is optimizing away the creation of
activation contexts. So we do get new objects after the sentinel, but since
we don't create new objects on *every* block activation, we eventually
catch up and get 0. This makes me wonder if the sentinel is actually
necessary. Even the classical interpreter VM recycles activation contexts,
and therefor shouldn't create a new object for every block activation.

We could have the contract offered by #allObjectsDo: be that all objects
that exist at the time of the method activation will be enumerated, but any
new objects created by the block will not. That would imply using a
sentinel. Or we could specify that #allObjectsDo: will enumerate objects
created in the block, but it's up to the caller to ensure that memory
doesn't grow faster than we can scan through it. That would imply using 0
as the termination condition for the loop. Either way, we should use
Levente's idea to prevent skipping large swathes of the object memory.

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