If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

baconize object initialization

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
10 years ago
10 years ago

People

(Reporter: shaver, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

10 years ago
(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.
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
OK, nm.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.