On 13.01.2014, at 13:16, David T. Lewis <lewis at mail.msen.com> wrote:

> 
> On Mon, Jan 13, 2014 at 12:28:33PM +0100, Bert Freudenberg wrote:
>> 
>> On 13.01.2014, at 02:13, David T. Lewis <lewis at mail.msen.com> wrote:
>> 
>>> On Sun, Jan 12, 2014 at 12:01:00PM -0800, Eliot Miranda wrote:
>>>> 
>>>> 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."
>>> 
>>> Dave
>>> 
>>> <InterpreterPrimitives-primitiveAllObjects-dtl.1.cs>
>> 
>> Nice, except that I'd fill the remaining slots with 0 instead of nil. Even better: allocate the array as object count + 1 and *always* put a 0 last. That way the image code cannot ever "forget" to check for 0.
>> 
> 
> Someone would surely accuse me of being an unreformed C programmer ;-)

Nah, I don't think so. It just mimics the old behavior of answering 0 after the last object. Simplifies the image code (which would otherwise have to keep track whether it enumerated nil yet or not).

> Another approach might be to provide an explicit object count in addition to the
> array of objects, so the primitive would answer an array with object count and
> with the all objects array.

That's even uglier ;^)

> Or we might force a GC in the primitive in order to prevent the condition from
> ever happening, at the cost of an unnecessary GC.

Forcing a GC would remove the neat feature of being able to access 

- Bert -

>> In the image I think the code should still prefer the someObject/nextObject interface, because allocating the large array is unnecessary in almost all cases. We could say a VM is allowed to fail the someObject/nextObject prims if it supports primitiveAllObjects, which otherwise is optional.
>> 
>> - Bert -