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 ;-)

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.

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.

> 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 -