first window, yay! Re: [Vm-dev] VM Maker: VMMaker.oscog-eem.399.mcz

[Eliot Miranda]

Hi Levente,


On Sat, Sep 21, 2013 at 11:39 AM, Levente Uzonyi <leves at elte.hu> wrote:

>
> Great progress. I've got a few questions about Spur and the bootstrap:
> - How will HashedCollections other than MethodDictionaries get rehashed?
> How #hash be calculated from #identityHash?
>

The bootstrap first builds an image in the new format and then finds all
classes in it that implement rehash and then uses the simulator to send
rehash to all objects to use their own rehash method to rehash them,
instead of assuming their format.  In fact, the bootstrap does not rehash
all objects that understand rehash since Symbol is one of them, and its
Symbol table is rehashed anyway.

hash is computed from identityHash without change, but scaledIdentityHash
is changed to avoid creating LargeIntegers (the larger identityHash needs
less shift also):
ProtoObjectPROTOTYPEscaledIdentityHash
"For identityHash values returned by primitive 75, answer
 such values times 2^8.  Otherwise, match the existing
 identityHash implementation"

^self identityHash * 256 "bitShift: 8"

- What will happen to primitive 138 and 139? Will we still be able to
> iterate over the objects in the order of their creation time?
>

That's much more difficult.  I'll add allInstances and allObjects
primitives which can answer the objects instantianeously without needing to
enumerate.  One issue is that the scavenger could fire at any time during
the enumeration and could tenure objects to old space so its in general not
possible to reliably enumerate via firstInstance/nextInstance
firstObject/nextObject.

Being able to enumerate in order of creation time is something the VM could
maintain in old space, keeping objects in order there-in.  But I'd rather
drop this property and allow the Spur GC to compact using best-fit and lazy
become, which will change the order of objects.  How important is being
able to enumerate in order of creation?  I think it's nice to have but
hardly essential.  What do y'all think?


> - IIUC the memory is more segmented. Will there be new GC primitives for
> various levels of garbage collection? What about the GC parameters?
>

That remains to be seen.  I take requests.  I take design suggestions.  But
I also like to keep things simple.

My current approach is to keep things as compatible as possible to ease
adoption.  Once it is adopted we can start to evolve to provide appropriate
and.or improved management facilities.


> - Are #become: and #becomeForward: optimized for the case where both
> objects use the same amount of memory?


Yes.  This case simply swaps contents and adjusts the remembered table
accordingly.  Tim also suggested optimizing the other case, copying into
the smaller object and only allocating one extra clone, which I'll
implement soon.


>
>
>
> Levente
>
>
> On Sat, 21 Sep 2013, btc at openinworld.com wrote:
>
>
>> commits at source.squeak.org wrote:
>>
>>>  Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>>> http://source.squeak.org/**VMMaker/VMMaker.oscog-eem.399.**mcz<http://source.squeak.org/VMMaker/VMMaker.oscog-eem.399.mcz>
>>>
>>> ==================== Summary ====================
>>>
>>> Name: VMMaker.oscog-eem.399
>>> Author: eem
>>> Time: 20 September 2013, 6:28:56.308 pm
>>> UUID: 89f8fefe-b59d-42d7-9c11-**7f848d0e5131
>>> Ancestors: VMMaker.oscog-eem.398
>>>
>>> A few isIntegerObject:'s => isImmediate:'s in primitives.
>>>
>>> More protocol.
>>>
>>> The Spur VM now draws its first window!!
>>>
>>>
>>>  A cheer goes up in the crowd of interested spectators.
>> Probably lots still to do, but its a nice concrete milestone.
>> Contributing is beyond me at this time, so I especially like to thank you
>> for this important initiative.
>>
>> cheers -ben
>>
>>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130922/9b5718bb/attachment-0001.htm