Use an IC when closing for-of iterators
Categories
(Core :: JavaScript Engine: JIT, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: iain, Assigned: iain)
References
(Blocks 1 open bug)
Details
Attachments
(15 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
We generate a lot of bytecode for for-of loops. A lot of that bytecode is dedicated to closing iterators on the way out. Many/most for-of loops are iterating over arrays or other collections that don't even have a return method. We can reduce bytecode size by folding the iterator closure code up in an IC.
| Assignee | ||
Comment 1•3 years ago
|
||
This initial implementation doesn't handle throw completions. Support for those is added in a later patch.
| Assignee | ||
Comment 2•3 years ago
|
||
Depends on D147344
| Assignee | ||
Comment 3•3 years ago
|
||
tryAttachNoReturnMethod covers built-in collections (arrays, maps, and sets), and any custom iterator that doesn't have a return method.
Depends on D147345
| Assignee | ||
Comment 4•3 years ago
|
||
Depends on D147346
| Assignee | ||
Comment 5•3 years ago
|
||
We had LoadDynamicSlot, but not LoadFixedSlot.
Depends on D147347
| Assignee | ||
Comment 6•3 years ago
|
||
Entering a stub frame is the same whether we're doing a callVM or a callJit. This aligns better with baseline and simplifies the getter/setter code.
At some point we could consider rewriting the Ion code to use AutoStubFrame.
Depends on D147348
| Assignee | ||
Comment 7•3 years ago
|
||
Depends on D147349
| Assignee | ||
Comment 8•3 years ago
|
||
This supports custom iterators with return methods. It is also necessary to support generators (which call the self-hosted GeneratorReturn function), although those won't work until a subsequent patch adds support for rectifier frames.
Depends on D147350
| Assignee | ||
Comment 9•3 years ago
|
||
Depends on D147351
| Assignee | ||
Comment 10•3 years ago
|
||
When closing a for-of iterator, we overwrite the iterator on the stack with undefined. Comments / commit messages say it's so the iterator doesn't get closed again in the catch block. But there's a for-of-iterclose trynote covering this code, so we never end up in the catch block, and this code is dead.
Depends on D147352
| Assignee | ||
Comment 11•3 years ago
|
||
The spec handles IteratorClose specially when the completion kind is 'throw' so that the original exception isn't overwritten by an exception that happens while closing the iterator. See https://tc39.es/ecma262/#sec-iteratorclose.
Depends on D147353
| Assignee | ||
Comment 12•3 years ago
|
||
We guard on the specific function/script, so nargs is constant for a particular IC stub. Generating a rectifier frame is overkill.
The main use case for this is generators: GeneratorReturn takes one argument.
Depends on D147354
| Assignee | ||
Comment 13•3 years ago
|
||
Depends on D147355
| Assignee | ||
Comment 14•3 years ago
|
||
In the next patch, we want to change the bailout kind in BaselineStackBuilder. This patch sets the initial bailout kind earlier, so that we don't clobber the update.
Depends on D147356
| Assignee | ||
Comment 15•3 years ago
|
||
If we throw an exception while building the stack frame in BailoutIonToBaseline, we will skip try/catch blocks in that frame. Throwing in FinishBailoutToBaseline ensures that we unwind correctly.
Depends on D148332
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0f94133f476e
https://hg.mozilla.org/mozilla-central/rev/6c908030c328
https://hg.mozilla.org/mozilla-central/rev/bbfedd0e08ce
https://hg.mozilla.org/mozilla-central/rev/9d37be10da8f
https://hg.mozilla.org/mozilla-central/rev/874a4adcb3bf
https://hg.mozilla.org/mozilla-central/rev/d20dcc34e87c
https://hg.mozilla.org/mozilla-central/rev/4235a298993a
https://hg.mozilla.org/mozilla-central/rev/1d912ad801b0
https://hg.mozilla.org/mozilla-central/rev/7d425224ec84
https://hg.mozilla.org/mozilla-central/rev/cc2d84593658
https://hg.mozilla.org/mozilla-central/rev/7ad24b936f3b
https://hg.mozilla.org/mozilla-central/rev/347c2d2b6751
https://hg.mozilla.org/mozilla-central/rev/d26c5eb9eb33
https://hg.mozilla.org/mozilla-central/rev/0c4b84f3d824
https://hg.mozilla.org/mozilla-central/rev/0b909b1ebdf8
Description
•