[Vm-dev] A stab at explaining Spur

[Eliot Miranda]

Hi Ryan,

   just one small thing to add to your description...

On Fri, Aug 14, 2015 at 6:43 PM, Ryan Macnak <rmacnak at gmail.com> wrote:

>
> On Fri, Aug 14, 2015 at 1:53 AM, Clément Bera <bera.clement at gmail.com>
> wrote:
>
>>
>> Hello Stefan, Ryan and all,
>>
>> I checked the paper where I read it (unfortunately it was rejected) and
>> the exact sentence was:
>>
>> *In some implementations (e.g. Dart [22] and PyPy [3]), object header and
>> attribute storage can be separated, so the attribute storage can be
>> relocated in order to grow. *
>>
>> *[3]C. F. Bolz. Efficiently implementing objects with maps
>> <http://morepypy.blogspot.fr/2010/11/efficiently-implementing-python-objects.html>,
>> 2010. [22]F. Schneider. Compiling dart to efficient machine code
>> <https://www.dartlang.org/slides/2013/04/compiling-dart-to-efficient-machine-code.pdf>,
>> 2012.*
>>
>> When I read F. Boltz. post, it looks like to me that in Pypy each
>> instance of a class has a pointer to its map and its storage. The storage
>> seems to be at a different location than the object's header and holds the
>> instance variable values. To me it sounds very much like the object is
>> 'split' to be able to grow the storage if a new instance variable is added
>> for a specific instance. Accessing an object instance variable requires an
>> extra indirection through the storage pointer. Is there something I miss
>> there ? It looks like the paper we wrote with Eliot could definitely apply
>> there in order to speed up instance variable access by removing the
>> indirection to the storage.
>>
>> In the talk compiling dart to efficient machine code, one section deals
>> about Javascript and V8. Objects are described in V8 (slide 29) as having a
>> pointer to their Map, their properties and their elements, which to me
>> sounds similar to Cincom Smalltalk design (the object header is separated
>> from the value of the instance variables). However the talk then discusses
>> the Dart implementation and it's not the case there. I guess I got confused
>> as the talk is about Dart but this part of the talk is about Javascript.
>>
>
> The split in V8 isn't between an object's header and its properties. It is
> between the header + the fast properties the hidden-class machinery could
> figure out ahead of allocation and the slow properties it could not.
>

Talking with members of the V8 team at ISMM I was told that V8 also has a
split between an array's header and its elements.  So at least for arrays
there is always an indirection.


> For instance, if I write well-behaved code like
>
> function Point(x, y) {
>   this.x = x;
>   this.y = y;
> }
>
> var p = new Point(3, 4);
>
> p would in one block have a reference to its hidden-class, the properties
> 'x' and 'y', a bit of speculative space for properties that might be added
> later, and space to hang a properties overflow array. Access to x or y is a
> simple direct load and we're happy.
>
> However, if I start treating objects like dictionaries as Javascript
> allows, and later I do,
>
> p.someNewIdentifier = 5;
>
> enough times or,
>
> p["not an identifier"] = 6;
>
> the new properties go into the overflow array, and they are more costly to
> access.
>
> The actual mechanics are bit more complicated than this depending on the
> property name and value and the size of the object. Adding a function
> property may create a new hidden-class but leave the object's layout
> unchanged. Adding a property whose name isn't an identifier or too many
> properties may transition the object to dictionary-mode, where all the
> properties are indirect. Adding a property whose name is an identifier may
> try to use some of the left-over inline slots first and try give objects
> that add the same properties the same hidden class. So if something like
>
> var p = new Point(3, 4);
> p.z = 6;
>
> happens often, all these objects share a hidden-class and we reduce
> polymorphism.
>
> If I do, 'delete p.x;' the slot where x was is filled in with a special
> value indicating the property no longer exists ('the hole').
>
> The Spur model might be interesting in the Javascript context if it is
> used to avoid the memory overhead of allocating with extra space to deal
> with overflow.
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150814/2ad2d615/attachment.htm