<div dir="ltr">Hi Nicolas,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 10:20 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.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 dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">
<div><div class="h5">2014/1/13 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>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" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
><br>
</div><div>> > 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><span><font color="#888888">-- <br>best,<div>Eliot</div>
</font></span></div></div>
<br><br></blockquote></div></div><div>Oh, I missed this one. I can't check now, could it cleanly address my hugly trick of modifying the header like explained at<br><a href="http://smallissimo.blogspot.fr/2013/04/still-hacking-largeintegerplugins-in.html" target="_blank">http://smallissimo.blogspot.fr/2013/04/still-hacking-largeintegerplugins-in.html</a> ?</div>
</div></div></div></blockquote><div><br></div><div>It would on SqueakV3. On Spur it could be more difficult as there's no support for one-double-word free objects, so one can't free a singe 64-bit pair (objects are rounded up to 64-bits in length). But perhaps you should inflict this on me to force my hand ;-). The problem is that a single 64-bit word is big enough for an object header but not for an object header plus an indirection in the first slot, which takes 129 bits, when rounded up to a 64-bit boundary. So such fragments are only reclaimable if an object next to them is freed. They can't be compacted because there's no forwarding pointer. So I expect in Spur I'd just have to disable the code and always create the copy. However, what *can* be shortened, always, is the last object in eden. So if the object is newly created it can easily be shortened; all that needs ot happen is the allocation pointer, freeStart, is cut-back.</div>
<div><br></div><div>HTH,</div></div><div>Eliot</div>
</div></div>