Closed Bug 883661 Opened 9 years ago Closed 9 years ago

Handle lazy functions in FastInvokeGuard

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: bhackett1024, Unassigned)

References

Details

Attachments

(1 file)

Attached patch patchSplinter Review
Currently, FastInvokeGuard is not able to use its Ion fast path if the called function is initially lazy.  This causes a sort() operation in ss-string-tagcloud to take twice as long when using lazy parsing, and slow the benchmark down by about 20%.  The attached patch fixes this, and also fixes a similar issue when pattern matching numeric comparators during sorts.  (The comparator used in tagcloud actually happens to be doing a numeric sort, but the pattern matching isn't able to catch this.)  With this fix, string-tagcloud takes about the same with vs. without lazy parsing.
Attachment #763268 - Flags: review?(luke)
Attachment #763268 - Flags: review?(luke) → review+
Looks like this regressed ecma/Array/15.4.4.5-3.js.
Blech, the enum values for ComparatorMatchResult were involved with some undocumented invariants.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ede58026dcb5
Ouch.  Double ouch: it looks like there is a second instance of this: SortComparatorInt32.

In push to fix the above, could you add a Match_COUNT and then JS_STATIC_ASSERT(Match_Count == JS_ARRAY_LENGTH(SortComparatorNumerics)) and also for SortComparatorInt32?
https://hg.mozilla.org/mozilla-central/rev/849e6303ac21
https://hg.mozilla.org/mozilla-central/rev/ede58026dcb5
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.