[Vm-dev] A stab at explaining Spur

[Ryan Macnak]

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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150814/eec616f0/attachment.htm