All users were logged out of Bugzilla on October 13th, 2018

Unexpected IonAbort on for..of statement across Array due to JSOP_SYMBOL

RESOLVED FIXED in mozilla37

Status

()

RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: lth, Assigned: bzbarsky)

Tracking

unspecified
mozilla37
x86_64
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Compiling FF with DEBUG in release mode and IONFLAGS=aborts, I reliably get these messages when I iterate across Array elements using for..of (which is pretty sweet syntax):

[IonAbort] Unsupported opcode: symbol (line 316)
[IonAbort] aborted @ file:///Users/lhansen/moz/sab-demo/util/parinvoke-master.js:316
[IonAbort] Disabling Ion mode 0 compilation of script file:///Users/lhansen/moz/sab-demo/util/parinvoke-master.js:312

(Likely this is just a to-be-implemented feature but I could not find a bug tracking it.)
Ion is not compiling JSOP_SYMBOL, we should really fix that...
(Assignee)

Updated

4 years ago
Summary: Unexpected IonAbort on for..of statement across Array → Unexpected IonAbort on for..of statement across Array due to JSOP_SYMBOL
(Assignee)

Comment 2

4 years ago
Created attachment 8535691 [details]
Simple performance testcase
(Assignee)

Comment 3

4 years ago
Created attachment 8535692 [details] [diff] [review]
Ion-compile JSOP_SYMBOL

This just copy/pastes what Ion does for JSOP_STRING, with the body of the case based on what baseline does for JSOP_SYMBOL.  The time on the silly testcase is reduced from 4100ms to about 1900ms.
Attachment #8535692 - Flags: review?(jdemooij)
(Assignee)

Updated

4 years ago
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
(Assignee)

Comment 4

4 years ago
Jason, we enabled symbols for for-of in 36, right?  Do we need to backport this to 36, or is this not a big worry because web uptake of for-of is pretty low?
Flags: needinfo?(jorendorff)
This is not a big worry because web uptake of for-of is pretty low. I wouldn't backport if it was me.

(If we want to backport to make a good first impression, I'm OK with it if Jan is. But I don't think it's necessary.)
Flags: needinfo?(jorendorff)
Comment on attachment 8535692 [details] [diff] [review]
Ion-compile JSOP_SYMBOL

Review of attachment 8535692 [details] [diff] [review]:
-----------------------------------------------------------------

Nice, thanks!

::: js/src/vm/Runtime.h
@@ +445,5 @@
>      ImmutableSymbolPtr &get(JS::SymbolCode code) {
>          return get(size_t(code));
>      }
> +
> +    const ImmutableSymbolPtr &get(JS::SymbolCode code) const {

Nit: I think we can just make the non-const version const, instead of having both non-const and const? Shell seems to compile here..
Attachment #8535692 - Flags: review?(jdemooij) → review+
Backporting is fine btw if you want, it might be nice for some chrome code or extensions...
(Assignee)

Comment 8

4 years ago
> Nit: I think we can just make the non-const version const

Right you are.  I thought there would be code that called init() no these, but the init code looks like this:

155     wellKnownSymbols = cx->new_<WellKnownSymbols>();
....
160     ImmutableSymbolPtr *symbols = reinterpret_cast<ImmutableSymbolPtr *>(wellKnownSymbols);
161     for (size_t i = 0; i < JS::WellKnownSymbolLimit; i++) {
...
167         symbols[i].init(symbol);

so it never uses the get() API because it has that manual reinterpret_cast bit (!).  I guess whoever decides to fix that gets to deal with the resulting issues.

I'm not going to worry about backports.
Blocks: 874580
https://hg.mozilla.org/mozilla-central/rev/3127df59e0dc
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Depends on: 1143194
Depends on: 1275001
You need to log in before you can comment on or make changes to this bug.