Closed
Bug 1094491
Opened 10 years ago
Closed 10 years ago
Generate baseline get ICs for accessor properties before calling the getter
Categories
(Core :: JavaScript Engine: JIT, defect)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox40 | --- | fixed |
People
(Reporter: bzbarsky, Assigned: jschulte)
References
Details
Attachments
(5 files, 7 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
jschulte
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jschulte
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jschulte
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jschulte
:
review+
|
Details | Diff | Splinter Review |
Like bug 1089050 but for getters. This part might get a bit complicated.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
I'll see if I can find time for this, but we have a bunch of IsCacheableGetPropCall callers, looks like, and I assume I need to refactor all of them. And I'm not sure about ordering wrt typemonitor stubs and the like....
Reporter | ||
Comment 3•10 years ago
|
||
Johannes, are you interested in taking a look at this one?
Flags: needinfo?(j_schulte)
Assignee | ||
Comment 4•10 years ago
|
||
Definitely, sounds interesting. Not sure, if I'm able to get to it next week, but the week after that, I can definitely look into this. Feel free to take it, if it's urgent.
Flags: needinfo?(j_schulte)
Reporter | ||
Comment 5•10 years ago
|
||
This isn't urgent; happy to leave it for you. ;)
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8530933 -
Flags: review?(efaustbmo)
Assignee | ||
Comment 7•10 years ago
|
||
Attachment #8530934 -
Flags: review?(efaustbmo)
Assignee | ||
Comment 8•10 years ago
|
||
Attachment #8530935 -
Flags: review?(efaustbmo)
Assignee | ||
Comment 9•10 years ago
|
||
Passes tests and improves microbenchmark by ~50%.
Attachment #8530939 -
Flags: review?(efaustbmo)
Comment 10•10 years ago
|
||
I just want to ensure that we can do this pre-emitting with respect to attaching fallback stubs and checking stub invalidation. As long as that is true, then these patches should look good.
ni? djvj
Flags: needinfo?(kvijayan)
Comment 12•10 years ago
|
||
Comment on attachment 8530933 [details] [diff] [review]
Part 1: GETPROP
Review of attachment 8530933 [details] [diff] [review]:
-----------------------------------------------------------------
Refactor looks good. I'm a little concerned about the new handling of MAX_OPTIMIZED_STUBS. See below. Discussion welcome.
::: js/src/jit/BaselineIC.cpp
@@ +7008,5 @@
> + return false;
> + }
> +
> + // After the Genericstub was added, we should never reach the Fallbackstub again.
> + MOZ_ASSERT(!stub->hasStub(ICStub::GetProp_Generic));
This assert seems out to place, see below.
@@ +7026,5 @@
> +
> + if (attached)
> + return true;
> +
> + if (stub->numOptimizedStubs() >= ICGetProp_Fallback::MAX_OPTIMIZED_STUBS) {
So now we can have unlimited numbers of getter stubs, right?
```
var i;
var o = {};
for (i = 0; i < BIG_NUMBER; i++) {
Object.defineProperty(o, "x", { get: (() => 4) });
o.x;
}
```
I think the right thing to do here is to try and reset the stubs right at the beginning with the assert above it. If we did that, don't try to emit the getter stub, and just do the ComputeGetPropResult call through adding the monitor stub, and then return.
Attachment #8530933 -
Flags: review?(efaustbmo)
Comment 13•10 years ago
|
||
(In reply to Eric Faust [:efaust] from comment #11)
> ni? jandem for another possible pair of eyes.
We discussed the stub invalidation changes on IRC a while ago, so clearing NI.
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 14•10 years ago
|
||
Attachment #8530933 -
Attachment is obsolete: true
Attachment #8542298 -
Flags: review?(efaustbmo)
Assignee | ||
Comment 15•10 years ago
|
||
Attachment #8530934 -
Attachment is obsolete: true
Attachment #8530934 -
Flags: review?(efaustbmo)
Attachment #8542301 -
Flags: review?(efaustbmo)
Assignee | ||
Comment 16•10 years ago
|
||
Attachment #8530935 -
Attachment is obsolete: true
Attachment #8530935 -
Flags: review?(efaustbmo)
Attachment #8542302 -
Flags: review?(efaustbmo)
Assignee | ||
Updated•10 years ago
|
Attachment #8542301 -
Attachment description: getelem_v2.patch → PART 2: GETELEM
Comment 17•10 years ago
|
||
Comment on attachment 8542298 [details] [diff] [review]
Part 1: GETPROP
Review of attachment 8542298 [details] [diff] [review]:
-----------------------------------------------------------------
Good. I'm glad that worked out to be as easy as it seemed in the last review. Thanks for doing this. r=me
Attachment #8542298 -
Flags: review?(efaustbmo) → review+
Comment 18•10 years ago
|
||
Comment on attachment 8542301 [details] [diff] [review]
PART 2: GETELEM
Review of attachment 8542301 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good.
::: js/src/jit/BaselineIC.cpp
@@ +3793,5 @@
>
>
> +static bool TryAttachNativeGetValueElemStub(JSContext *cx, HandleScript script, jsbytecode *pc,
> + ICGetElem_Fallback *stub, HandleObject obj,
> + HandleValue key)
I understand why this doesn't take an |attached| outparam (it will be ignored in the current codeflow), but it's a little weird to see the difference.
Attachment #8542301 -
Flags: review?(efaustbmo) → review+
Comment 19•10 years ago
|
||
Comment on attachment 8542302 [details] [diff] [review]
Part 3: GETGNAME
Review of attachment 8542302 [details] [diff] [review]:
-----------------------------------------------------------------
Yep.
::: js/src/jit/BaselineIC.cpp
@@ +6036,5 @@
> + MOZ_ASSERT(global->is<GlobalObject>());
> +
> + RootedId id(cx, NameToId(name));
> +
> + // The property must be found, and it must be found as a normal data property.
I very much doubt that ;)
Attachment #8542302 -
Flags: review?(efaustbmo) → review+
Comment 20•10 years ago
|
||
Comment on attachment 8530939 [details] [diff] [review]
Part 4: Add assert in UpdateExistingGetPropCallStubs
Review of attachment 8530939 [details] [diff] [review]:
-----------------------------------------------------------------
:)
Attachment #8530939 -
Flags: review?(efaustbmo) → review+
Assignee | ||
Comment 21•10 years ago
|
||
Assignee: nobody → j_schulte
Attachment #8542298 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8588304 -
Flags: review+
Assignee | ||
Comment 22•10 years ago
|
||
Attachment #8542301 -
Attachment is obsolete: true
Attachment #8588305 -
Flags: review+
Assignee | ||
Comment 23•10 years ago
|
||
Attachment #8542302 -
Attachment is obsolete: true
Attachment #8588306 -
Flags: review+
Assignee | ||
Comment 24•10 years ago
|
||
Attachment #8530939 -
Attachment is obsolete: true
Attachment #8588307 -
Flags: review+
Assignee | ||
Comment 25•10 years ago
|
||
Keywords: checkin-needed
Comment 26•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e68045bf8272
https://hg.mozilla.org/integration/mozilla-inbound/rev/97b21e438a35
https://hg.mozilla.org/integration/mozilla-inbound/rev/f77994182908
https://hg.mozilla.org/integration/mozilla-inbound/rev/3693f117ad50
Flags: in-testsuite+
Keywords: checkin-needed
Comment 27•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e68045bf8272
https://hg.mozilla.org/mozilla-central/rev/97b21e438a35
https://hg.mozilla.org/mozilla-central/rev/f77994182908
https://hg.mozilla.org/mozilla-central/rev/3693f117ad50
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in
before you can comment on or make changes to this bug.
Description
•