Closed Bug 1106828 Opened 5 years ago Closed Last year

[meta] Unboxed objects and arrays


(Core :: JavaScript Engine, defect)

Not set





(Reporter: bhackett, Unassigned)


(Blocks 1 open bug)


(Keywords: meta)

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.
Depends on: 1107496
Depends on: 1115886
Depends on: 1116017
Depends on: 1116855
Depends on: 1128076
Depends on: 1128084
Depends on: 1128644
Depends on: 1130903
Depends on: 1131403
Depends on: 1133254
Depends on: 1133369
Blocks: 1090583
Depends on: 1135423
Depends on: 1135816
Depends on: 1135897
Depends on: 1137180
Depends on: 1137497
Depends on: 1137978
Depends on: 1140888
Depends on: 1146597
Depends on: 1148661
Depends on: 1153266
Depends on: 1157703
Depends on: 1157809
Depends on: 1160887
Depends on: 1161077
Depends on: 1162199
Depends on: 1163091
Depends on: 1165392
Depends on: 1165463
Depends on: 1166709
Depends on: 1170372
Depends on: 1172943
Depends on: 1175165
Depends on: 1176451
Depends on: 1176751
Depends on: 1198861
Depends on: 1398768
All the dependent bugs have been fixed
Is there something else to do here?
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.