429787 - baconize object initialization

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Current codegen for object initialization:

js> function g() { return {a:5, b:1, c:"cookie"}; }
js> dis(g)
main:
00000:  newinit 1
00002:  int8 5
00004:  initprop "a"
00007:  one
00008:  initprop "b"
00011:  string "cookie"
00014:  initprop "c"
00017:  endinit

I propose that we:
(push the property values in inverse order)
  string "cookie"
  one
  int8 5
(newinit, adding the number of properties as an operand)
  newinit 1 3
(initprop in sequence)
  initprop "a"
  initprop "b"
  initprop "c"
(endinit, with the offset back to newinit as an operand)
  endinit 9

ENDINIT would fill the propcache entry for NEWINIT to hold the resulting shape of the object, via a pointer to the appropriate property in the tree.  Finding the cache entry during NEWINIT execution would create an object, grow the slots vector in one shot, set scope->lastProp and such, and then pop the stack into those slots.

Pruning of the property tree during GC would have to invalidate the cache appropriately.  We couldn't do this 100% compatibly if there are setters on Object.prototype; I propose a cheap test for that and Array.prototype on which to condition this and other fast paths.

Tell me how wrong this idea is!

Comment 1

[Igor Bukanov]

(In reply to comment #0)
> Current codegen for object initialization:
> 
> js> function g() { return {a:5, b:1, c:"cookie"}; }

> I propose that we:
> (push the property values in inverse order)
>   string "cookie"
>   one
>   int8 5

This would not work due to possible side effects in values like in:

var x = 0;
var obj = { a: (++x, 0), b: x};

It should be  straightforward to fix this since initprop can access the pushed values in the reverse order. 
But it also suggests instead of having initptop/endinit to have single variable-length bytecode like initobj that takes the list of indexes of property names together with flags describing getters/setters. Then the implementation of this bytecode can define the properties in any order as it wishes.

Comment 2

[Brendan Eich [:brendan]]

ECMA does specify order of evaluation, so care is needed.

But what problem is this bug solving? If there's a perf prob it has to be due to a loop creating the same initialiser over and over, but I did "baconize" JSOP_INITPROP already. Benchmark and profile first, then file. As stated, this bug is probably invalid.

/be

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

OK, nm.