Last Comment Bug 649376 - JM+TI: direct instance property accesses
: JM+TI: direct instance property accesses
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Brian Hackett (:bhackett)
:
Mentors:
Depends on: 649593
Blocks: 619423
  Show dependency treegraph
 
Reported: 2011-04-12 09:42 PDT by Brian Hackett (:bhackett)
Modified: 2011-04-30 18:47 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WIP (23.75 KB, patch)
2011-04-12 12:20 PDT, Brian Hackett (:bhackett)
no flags Details | Diff | Review
patch (58.19 KB, patch)
2011-04-12 20:41 PDT, Brian Hackett (:bhackett)
no flags Details | Diff | Review

Description Brian Hackett (:bhackett) 2011-04-12 09:42:52 PDT
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).
Comment 1 Brian Hackett (:bhackett) 2011-04-12 12:20:16 PDT
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
Comment 3 Danial Horton 2011-04-13 00:43:57 PDT
Brian, some mozillazine uses are interested in knowing if the 566.5% improvement in V8Bench is intended, or an accidental breaking of the benchmark.
Comment 4 Jan de Mooij [:jandem] 2011-04-13 01:37:35 PDT
(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.
Comment 5 Brian Hackett (:bhackett) 2011-04-13 06:08:52 PDT
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.
Comment 6 Brian Hackett (:bhackett) 2011-04-30 18:47:41 PDT
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

Note You need to log in before you can comment on or make changes to this bug.