[Vm-dev] A stab at explaining Spur
bera.clement at gmail.com
Fri Aug 14 13:55:44 UTC 2015
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
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  and PyPy ), object header and
> attribute storage can be separated, so the attribute storage can be
> relocated in order to grow.
> > C. F. Bolz. Efficiently implementing objects with maps, 2010.
> > F. Schneider. Compiling dart to efficient machine code, 2012.
> After a brief discussion with Carl Friedrich, this blog post is slightly
> 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
> (_make_subclass_size_n (only ever used for n==5))
> A little more tangible:
> > 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
> 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 Marr
> Johannes Kepler Universität Linz
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev