<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 3:59 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Mon, Jan 13, 2014 at 09:26:31AM -0800, Eliot Miranda wrote:<br>
> Hi David,<br>
><br>
> On Sun, Jan 12, 2014 at 5:13 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> > 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>
> > > > 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,<br>
> > 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<br>
> > "allObjects do:" -<br>
> > > which might be implemented as a primitive in some VMs soonish. It<br>
> > *should not*<br>
> > > enumerate objects created after calling the method.<br>
> > ><br>
> ><br>
> ><br>
> > 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<br>
> > 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<br>
> > 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<br>
> > block<br>
> > > didn't create a new object (the block context was reused). So the code<br>
> > had<br>
> > > to be rewritten just to support closures.<br>
> > ><br>
> > > Spur has a generation scavenger operating in a distinct new space and<br>
> > that<br>
> > > doesn't jive well with a consistent ordering at all. So far the system<br>
> > 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).<br>
> > 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<br>
> > 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<br>
> > called, excluding those<br>
> > that may be garbage collected as a side effect of allocating the<br>
> > result array. Multiple<br>
> > references to nil in the last slots of the array are an indication<br>
> > that garbage collection<br>
> > occured, such that some of the unreferenced objects that existed<br>
> > at the time of calling<br>
> > the primitive no longer exist. Sender is responsible for handling<br>
> > multiple references to<br>
> > nil in the result array."<br>
> ><br>
><br>
> Instead of filling the unused slots with nil or 0, I think you should<br>
> shorten the object so that it contains each object only once, and contains<br>
> only the objects. Cog contains some code for shortening. See<br>
> [New]ObjectMemory>>shorten:toIndexableSize:.<br>
><br>
<br>
</div></div>That would be a better solution. However, I cannot offer an implementation<br>
in the near term because of:<br>
<br>
shorten: obj toIndexableSize: nSlots<br>
"Currently this works for pointer objects only, and is almost certainly wrong for 64 bits."<br>
<br>
Given that this is currently intended for pointer objects, it is probably<br>
fairly straightforward to get it working on the 64-bit object memory. In fact,<br>
it might already work as written. But I think that it will take some time to<br>
test so it's not going to happen tonight.<br>
<br>
We could consider a variation on Bert's suggestion, in which the result array<br>
might have trailing zeros if garbage collection has occurred. Later the primitive<br>
can be improved with shorten:toIndexableSize: after which the trailing zeros<br>
will never occur in practice. That would still put the burden on the image<br>
to ignore the trailing junk, so I don't know if it would be worth doing.<br></blockquote><div><br></div><div>There's no point hurrying a thing like this. Best to do it right. Take your time and answer an Array of the objects and nothing but the objects :-). We're essentially aiming at 4.6 now so there's lots of time to test.</div>
</div>-- <br>best,<div>Eliot</div>
</div></div>