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

[Eliot Miranda]

Hi Igor,


On Sun, Oct 20, 2013 at 6:38 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 21 October 2013 00:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>>
>> Hi Igor,
>>
>> On Sun, Oct 20, 2013 at 6:42 AM, Igor Stasenko <siguctua at gmail.com>wrote:
>>
>>>
>>> On 22 September 2013 20:29, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>> indeed.
>>> i think we could breathe more freely if VM wouldn't be obliged to expose
>>> heap enumeration/walking primitives.. I just wonder, if it is possible to
>>> provide alternatives for most cases:
>>>  - finding all instances
>>>  - finding all pointers to subject
>>> so the heap walking primitives can R.I.P.
>>> .. but there could be more, which we may need and which would require
>>> heap walking.
>>> what you think?
>>>
>>
>> I much prefer having allInstances and allObjects primitives.  I'll be
>> implementing them.  In VisualWorks we also implemented allInstancesOfAny:
>> to collect all instances of a set of classes, useful for the ClassBuilder,
>> and also for odd uses like enumerating all fonts in one pass.
>>
>>
> and what about graph traversal prim?
> by having it (and possibly one extra prim, which answers all roots known
> by VM,
> if we cannot get roots in some other way already),
> one can easily implement all of the rest:
>
> roots := VM primAllRoots.
> allObjects := VM primGraphScan: roots ignoring: #().
>
> allInstances := allObjects select: [:ea | myclasses includes: ea class].
>
> and in constrast to heap walking, this graph traversal will not give false
> positives (objects
> which not reachable anymore, but listed because GC didn't caught them yet).
>

That's a great idea.  This is guts of the segment writing primitive isn't
it?  And we need that.  For allObjects it seems to me that simplest is just
a full GC, which can count the number of objects as a side-effect, and then
create a container large enough to hold that number of large objects.  And
that makes me think that allInstances is a good time to do a GC also.  So
you might combine the primitive with a GC pass.

I *think* all you need is in the repository now.  You can create a
bootstrap image using

(SpurBootstrap32 new on: 'pharo.image')
 transform;
 saveTransformedImage

You then can either play with that directly using

SpurBootstrap32 new launchSaved

or write it to a snapshot using

SpurBootstrap32 new writeSnapshotOfTransformedImage

and then launch via

| vm | vm := StackInterpreterSimulator newWithOptions: #(ObjectMemory
Spur32BitMemoryManager). vm objectMemory setCheckForLeaks: -1. vm openOn:
'spur.image'. vm openAsMorph; run

I use an image with a read-eval-print-loop in it so I can type expressions
at it for testing.  But you can also do hacks like

| vm | vm := StackInterpreterSimulator newWithOptions: #(ObjectMemory
Spur32BitMemoryManager). vm objectMemory setCheckForLeaks: -1. vm openOn:
'spur.image'.
vm initStackPages.
vm push: ...expression to push receiver...
vm push: ...expression to create arg...
vm primitiveMyNewPrimitive

to get to to run your primitive directly.



>  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?
>>>>
>>>>
>>> IMO, i would never make any assumptions, in which order objects are
>>> located on heap nor in which order
>>> they get enumerated. "Heap" word says for itself here. (and anyone who
>>> thinks otherwise should be
>>> shot on sight :)
>>>
>>
>> Agreed, but once the VM was simple and so we could get away with it.
>>
>>
>>>   - 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
>>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>


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