<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 11, 2014 at 5:12 PM, Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div>
<div>On 1/11/2014 4:26 PM, Colin Putney
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"></div></blockquote></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
It does not skip over the sentinel. It encounters the "end" earlier
because you create a new object after the sentinel was created.<br>
If you do Object new nextObject you get 0. So when the proxy is
materialized and then gets sent nextObject it returns 0</div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Colin</div><div><br></div><div><br></div></div><br></div></div>