[Vm-dev] Re: allObjectsDo:
Bert Freudenberg
bert at freudenbergs.de
Mon Jan 13 14:49:36 UTC 2014
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 -
More information about the Vm-dev
mailing list