[Vm-dev] A stab at explaining Spur

[Clément Bera]

Ok I think I understand now. Thank you for the explanation. The approach is
different. I believe V8 has the same design than you have based on the talk
I referenced.

There are pros and cons for both techniques.

2015-08-14 14:59 GMT+02:00 Stefan Marr <smalltalk at stefan-marr.de>:

>
> Hi Clément:
>
> > On 14 Aug 2015, at 10:53, Clément Bera <bera.clement at gmail.com> wrote:
> >
> > 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, 2010.
> > [22]F. Schneider. Compiling dart to efficient machine code, 2012.
>
> After a brief discussion with Carl Friedrich, this blog post is slightly
> outdated.
> Each object is allocated with 5 fields. I think the last one can be used,
> if needed, to refer to an extra extension/storage array.
> So, objects are not split in the sense you got in mind. But they can have
> two parts.
> This is pretty common the Truffle Object Model uses the same strategy, as
> do I in my SOM implementations.
> [For Smalltalks, the strategy is also nice, because it gives you fast,
> object-table like become, without any need for barriers.]
>
> Main drawback of the approach is that objects have a rather large size.
> But so far that was neither for PyPy nor Truffle a real issue.
>
> For details, see
> https://bitbucket.org/pypy/pypy/src/7089cedc919340a0c07f78cc952d5760146f7d86/pypy/objspace/std/mapdict.py?at=default#mapdict.py-537
> (_make_subclass_size_n (only ever used for n==5))
>
> A little more tangible:
>
> https://github.com/smarr/RTruffleSOM/blob/master/src/som/vmobjects/object.py
>
> > 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.
>
> So, this is only true for fields that don’t fit into the slots that are
> directly following the ‘header’.
>
> > I am waiting for other people comments but to me it looks like the
> memory representation where the object’s header is separated from the the
> object's fields is used in Javascript V8 and Pypy, as explained in the 2
> references, and that they could benefit from our implementation.
>
> I don’t know about V8 for sure, but for PyPy (and Truffle, and SOM), I
> would not characterize it this way. The extension array is strictly
> optional for larger objects. From a conceptual point of view it is not
> designed as being split from the header. One could reduce the number of
> inlined fields to zero, and only keep the pointer to the storage array,
> but, this has a significant cost on my experience. (No, I don’t have
> numbers handy, but someone with an interest to easily do it by adjusting
> the min-max field number in PyPy).
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> Johannes Kepler Universität Linz
> http://stefan-marr.de/research/
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150814/2ce17989/attachment-0001.htm