883661 - Handle lazy functions in FastInvokeGuard

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Attachment: patch

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.

Comment 1

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/849e6303ac21

Comment 2

[Jason Orendorff [:jorendorff]]

Looks like this regressed ecma/Array/15.4.4.5-3.js.

Comment 3

[Brian Hackett [Laid off!]]

Blech, the enum values for ComparatorMatchResult were involved with some undocumented invariants.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ede58026dcb5

Comment 4

[Luke Wagner [:luke]]

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?

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/849e6303ac21
https://hg.mozilla.org/mozilla-central/rev/ede58026dcb5