2014/1/13 Eliot Miranda <eliot.miranda at gmail.com>

> Hi David,
>
> On Sun, Jan 12, 2014 at 5:13 PM, David T. Lewis <lewis at mail.msen.com>wrote:
>
>> On Sun, Jan 12, 2014 at 09:53:27PM +0100, Bert Freudenberg wrote:
>> >
>> > On 12.01.2014, at 20:42, David T. Lewis <lewis at mail.msen.com> wrote:
>> >
>> > > It is worth noting that allObjectsDo: relies on assumptions about how
>> > > the objects memory works internally. It requires that #someObject will
>> > > always answer the object at the lowest address in the object memory,
>> and
>> > > also that a newly allocated object will always be placed at a higher
>> > > address location than all other objects. Either of these assumptions
>> is
>> > > likely to be a problem as new and better object memories and garbage
>> > > collectors are implemented.
>> > >
>> > > Dave
>> >
>> > Right (as Eliot's vm-dev post shows).
>> >
>> > So IMHO the only sensible semantics of allObjectsDo: is as in
>> "allObjects do:" -
>> > which might be implemented as a primitive in some VMs soonish. It
>> *should not*
>> > enumerate objects created after calling the method.
>> >
>>
>>
>> On Sun, Jan 12, 2014 at 12:01:00PM -0800, Eliot Miranda wrote:
>> >
>> > The bug is in implementing allObjects in terms of someObject and
>> nextObject
>> > in the first place.  It's cheap and cheerful but horribly error-prone
>> and
>> > restrictive.  It's cheap because the collection of objects doesn't have
>> to
>> > be created, and on the original 16-bit Smalltalk machines that was
>> really
>> > important.  It's horribly restrictive because it assumes much about the
>> > implementation.
>> >
>> > Before closures a sentinel wasn't even needed because enumerating the
>> block
>> > didn't create a new object (the block context was reused).  So the code
>> had
>> > to be rewritten just to support closures.
>> >
>> > Spur has a generation scavenger operating in a distinct new space and
>> that
>> > doesn't jive well with a consistent ordering at all.  So far the system
>> is
>> > limping along by tenuring all objects on someObject and someInstance (so
>> > that newSpace is either empty, or doesn't contain any instances of a
>> > specific class) and having nextObject enumerate only objects in
>> oldSpace.
>> >
>> > But I think now we can afford a primitive that answers all the objects
>> > (remember that average object size means that such a collection will be
>> ~
>> > 10% of the heap, average object size in Squeak V3 is about 10.6 words).
>>  At
>> > least that's what Spur will do, along with an allInstancesOf: primitive.
>> >  And then the become example won't cause any problems at all.  Far more
>> > reliable.  I suppose there are circumstances when enumerating without a
>> > container is the only feasible approach, but VisualWorks has got along
>> with
>> > only an allObjects primitive for a long time now.  I suspect we can too.
>> >
>>
>> Implementation attached. Works on interpreter VM, not yet tested on Cog
>> but
>> it should be ok there also. If no objections or better suggestions I will
>> commit it to VMMaker tomorrow.
>>
>> InterpreterPrimitives>>primitiveAllObjects
>>         "Answer an array of all objects that exist when the primitive is
>> called, excluding those
>>         that may be garbage collected as a side effect of allocating the
>> result array. Multiple
>>         references to nil in the last slots of the array are an
>> indication that garbage collection
>>         occured, such that some of the unreferenced objects that existed
>> at the time of calling
>>         the primitive no longer exist. Sender is responsible for handling
>> multiple references to
>>         nil in the result array."
>>
>
> 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:.
>
> HTH
> --
> best,
> Eliot
>
>
> Oh, I missed this one. I can't check now, could it cleanly address my
hugly trick of modifying the header like explained at
http://smallissimo.blogspot.fr/2013/04/still-hacking-largeintegerplugins-in.html?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140113/b88219df/attachment.htm