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.