User:Waldo/JavaScript object layout/New object layout

The new object layout attempts to substantially unify the three object layouts of the old system into one. Objects continue to be represented using the same layout as in the old system:

class ObjectImpl
{
  Shape* shape;
  TypeObject* type;
  Value* slots;
  Value* elements;
};

The new object layout is interpreted in accordance with two latent subtypes: proxies and objects. (It's true that proxies are objects in the sense the ECMAScript spec uses the term. We use the term "object" here only because proxies are entirely separate beasts, and it becomes tedious referring to the other class as "native" objects, or some other laborious name. This may well change in the eventual implementation; indeed it probably will change.)

Proxies

Proxies are special beasts. The only interesting bit about them is that obj->isProxy is true for them. Proxy semantics are entirely defined by class hooks.

Proxies use the shape and type fields only. It is a category error to use either the slots or elements fields of a proxy.

Objects

All other objects interpret the object layout this way. For efficiency sometimes objects have extra memory allocated immediately after them as a "fused" allocation to store property values.

shape is used roughly as it was used for native objects under the previous system, but the domain of properties represented in it is narrower. It only represents properties which are not strings containing unsigned 32-bit integers: for example, "foo", " 0", "0 ", "-1", "4294967296", and object-valued properties (see E4X). It does not store information for properties like "0" or "4294967295".

type is used as it was before.

slots is always a pointer to a property value storage vector. It may or may not resolve to allocated space fused with the object. XXX more details

elements stores all information related to elements: strings containing unsigned 32-bit integers. (Thus shape and elements together represent the space of all possible property names.) All objects use this for element storage in the new layout. XXX EXCEPT FOR PROXIES elements is related, by pointer arithmetic, to an ElementsHeader structure with this layout:

class ElementsHeader
{
  uint32_t type;
  uint32_t length;
  uint32_t _1;
  uint32_t _2;
};

This class is similar to JSString in that it exists only as an ultimate superclass of specialized element subtypes. It is only useful when discriminated into the proper subclass.

ElementsHeader subclasses

DenseElementsHeader

Represents "dense" elements: that is, properties named as unsigned 32-bit integers when those properties are sufficiently densely packed that it makes sense to represent them as a vector. The exact determination of when elements should be dense isn't specified here at the moment.

SparseElementsHeader

Represents "sparse" elements: that is, elements that occur "infrequently" within the range from 0 to the maximum element represented. The exact determination of when elements should be sparse isn't specified here at the moment.

{Ui,I}nt{8,16,32}ElementsHeader

Represents the elements of a {Ui,I}nt{8,16,32}Array.

Uint8ClampedElementsHeader

Represents the elements of a Uint8ClampedArray.

Float32ElementsHeader

Represents the elements of a Float32Array.

Float64ElementsHeader

Represents the elements of a Float64Array.

ArrayBufferElementsHeader

Represents the element properties of an ArrayBuffer. XXX not necessary? ArrayBuffer element properties aren't actually special, except for how they're accessed in the old implementation

Each subclass has particular additional accessors and methods for the particularities of their different representations.