JM+TI: direct instance property accesses

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bhackett, Assigned: bhackett)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
For objects created in a few ways:

x = {a:0, b:1}

function Foo() {
  this.a = ...;
  this.b = ...;
}
x = new Foo();

We can prove that 'a' and 'b' will always be on the object in particular slots and will be added before they can be observed by any reads of the object.  This is trivial in the former case, requires some lightweight analysis in the latter case (all assignments to properties of 'this' always occur, and 'this' is not used in the constructor other than for assigning properties to).  This proof only holds if the properties are not subsequently deleted or redefined with e.g. a getter/setter, but those can be statically guarded against in the same way as for GNAME accesses.

For such properties, we can avoid doing an IC on the object's shape and just go to the slot directly.  With the patch in bug 648321 applied, if we know that the property is always in slot N and that the created objects always have at least N inline slots, the access will always be inline.  (if we don't know the number of inline slots wrt N we have to IC, as where N is stored could still vary between objects).
(Assignee)

Comment 1

6 years ago
Created attachment 525466 [details] [diff] [review]
WIP

Handles static initializers and singleton objects, not scripted new yet.

function foo(x) {
  for (var i = 0; i < 100000000; i++)
    x.f = x.f + 1;
}
foo({f:0});

js -m -n (old): 324
js -m -n (new): 180
js -j: 403
js -m: 557
d8: 293
Assignee: general → bhackett1024
(Assignee)

Comment 2

6 years ago
Created attachment 525610 [details] [diff] [review]
patch

http://hg.mozilla.org/projects/jaegermonkey/rev/440e9b0a41af
Attachment #525466 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 3

6 years ago
Brian, some mozillazine uses are interested in knowing if the 566.5% improvement in V8Bench is intended, or an accidental breaking of the benchmark.

Updated

6 years ago
Depends on: 649593
(In reply to comment #3)
> Brian, some mozillazine uses are interested in knowing if the 566.5%
> improvement in V8Bench is intended, or an accidental breaking of the benchmark.

The latter, just filed bug 649593.
(Assignee)

Comment 5

6 years ago
Yeah, gigantic improvements on AWFY are generally going to be breakage.  Gigantic regressions may or may not be breakage (but need fixing regardless).  I saw this last night but the v8-v4 harness in sunspider worked on my machine, I need to get my hands on whatever harness AWFY is using.
(Assignee)

Comment 6

6 years ago
Increase the number of fixed slots for objects with a given type if additional properties are added beyond the ones directly written in the constructor.  Saves a lot of malloc'ing in v8-splay, but curiously enough doesn't seem to improve that benchmark (need to look for the slowdown vs. TM branch elsewhere).

http://hg.mozilla.org/projects/jaegermonkey/rev/f1f907de8765
You need to log in before you can comment on or make changes to this bug.