<div dir="ltr"><div class="gmail_extra">Hi David,<br><br><div class="gmail_quote">On Sun, Jan 12, 2014 at 5:13 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Sun, Jan 12, 2014 at 09:53:27PM +0100, Bert Freudenberg wrote:<br>
><br>
> On 12.01.2014, at 20:42, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
</div><div class="im">> > It is worth noting that allObjectsDo: relies on assumptions about how<br>
> > the objects memory works internally. It requires that #someObject will<br>
> > always answer the object at the lowest address in the object memory, and<br>
> > also that a newly allocated object will always be placed at a higher<br>
> > address location than all other objects. Either of these assumptions is<br>
> > likely to be a problem as new and better object memories and garbage<br>
> > collectors are implemented.<br>
> ><br>
> > Dave<br>
><br>
> Right (as Eliot's vm-dev post shows).<br>
><br>
> So IMHO the only sensible semantics of allObjectsDo: is as in "allObjects do:" -<br>
> which might be implemented as a primitive in some VMs soonish. It *should not*<br>
> enumerate objects created after calling the method.<br>
><br>
<br>
<br>
</div>On Sun, Jan 12, 2014 at 12:01:00PM -0800, Eliot Miranda wrote:<br>
><br>
> The bug is in implementing allObjects in terms of someObject and nextObject<br>
> in the first place. It's cheap and cheerful but horribly error-prone and<br>
> restrictive. It's cheap because the collection of objects doesn't have to<br>
> be created, and on the original 16-bit Smalltalk machines that was really<br>
> important. It's horribly restrictive because it assumes much about the<br>
> implementation.<br>
><br>
> Before closures a sentinel wasn't even needed because enumerating the block<br>
> didn't create a new object (the block context was reused). So the code had<br>
> to be rewritten just to support closures.<br>
><br>
> Spur has a generation scavenger operating in a distinct new space and that<br>
> doesn't jive well with a consistent ordering at all. So far the system is<br>
> limping along by tenuring all objects on someObject and someInstance (so<br>
> that newSpace is either empty, or doesn't contain any instances of a<br>
> specific class) and having nextObject enumerate only objects in oldSpace.<br>
><br>
> But I think now we can afford a primitive that answers all the objects<br>
> (remember that average object size means that such a collection will be ~<br>
> 10% of the heap, average object size in Squeak V3 is about 10.6 words). At<br>
> least that's what Spur will do, along with an allInstancesOf: primitive.<br>
> And then the become example won't cause any problems at all. Far more<br>
> reliable. I suppose there are circumstances when enumerating without a<br>
> container is the only feasible approach, but VisualWorks has got along with<br>
> only an allObjects primitive for a long time now. I suspect we can too.<br>
><br>
<br>
Implementation attached. Works on interpreter VM, not yet tested on Cog but<br>
it should be ok there also. If no objections or better suggestions I will<br>
commit it to VMMaker tomorrow.<br>
<br>
InterpreterPrimitives>>primitiveAllObjects<br>
"Answer an array of all objects that exist when the primitive is called, excluding those<br>
that may be garbage collected as a side effect of allocating the result array. Multiple<br>
references to nil in the last slots of the array are an indication that garbage collection<br>
occured, such that some of the unreferenced objects that existed at the time of calling<br>
the primitive no longer exist. Sender is responsible for handling multiple references to<br>
nil in the result array."<br></blockquote><div><br></div><div>Instead of filling the unused slots with nil or 0, I think you should shorten the object so that it contains each object only once, and contains only the objects. Cog contains some code for shortening. See [New]ObjectMemory>>shorten:toIndexableSize:. </div>
</div><br clear="all"><div>HTH</div>-- <br>best,<div>Eliot</div>
</div></div>