1106828 - [meta] Unboxed objects and arrays

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

With bug 1058340 done, the memory representation now used for typed objects is considerably more compact and efficient than that used for normal objects, since (a) values in typed objects are unboxed, and (b) typed objects are not extensible.

In many cases though, normal objects of a given type have consistent properties and consistent types for those properties.  It would be nice if we could use an unboxed representation for normal objects too.

There are two main design options with storing unboxed data in normal objects:

a) Store some of the properties in an unboxed format, and allow the object to be extensible with new (boxed) properties, while still keeping the old properties unboxed.

b) Store all properties in an unboxed format. If someone tries to add new properties to the object, the object is first converted to use a fully boxed representation.

Choosing between these is kind of tough, but I think we should do b) --- at least initially --- because this will be much simpler and because it will make it easy to minimize memory usage for these objects by using the same layout as inline typed objects (i.e. two words of header plus the unboxed data).  The typed object code is pretty well encapsulated from the rest of the object manipulation code, and using b) will allow us to use the same code for accessing unboxed objects.  Unboxed objects will be non-native and use the same (or almost the same) hooks as typed objects.

Unboxed arrays are a bit different from unboxed objects.  I think we need to support extensible unboxed arrays, as we often don't have (or trust) the nominal length given for an array when creating it.  So I think we need a new layout for unboxed arrays, a little bit simpler than for normal objects and something like:

[ shape type length data ]
                     ||
                     \/
[ initlen capacity  unboxed values ... ]

As with unboxed objects, if anything happens to the unboxed array that requires a different layout, like adding a named property, changing the element type or introducing a hole, we convert it to the normal boxed representation.

The last bit here is deciding when to use an unboxed representation for objects or arrays of a given type.  I think that basing this on the approach used in bug 1041688 would work well.  When we start creating objects of a given type we use a boxed representation and keep track of them in an array, and after creating some number of them or Ion compiling accesses using them, we look at the existing objects and decide whether to use an unboxed representation.  If we do decide to do so, the initial boxed objects are converted to the unboxed representation, and future objects of that type will start out unboxed.

Comment 1

[David Bruant]

All the dependent bugs have been fixed
Is there something else to do here?