Closed
Bug 1353170
Opened 7 years ago
Closed 7 years ago
Implement recover instructions for NewArrayIterator
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Core
JavaScript Engine: JIT
Tracking
()
RESOLVED
FIXED
mozilla55
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: evilpie, Assigned: evilpie)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files, 3 obsolete files)
353 bytes,
application/javascript
|
Details | |
8.79 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
I implemented recover instructions, but we don't actually seem to remove the allocation on the micro benchmark "destructuring.es6" from six-speed. I guess something else is keeping the object alive? We are reading/writing fixed slots on that object. Nicolas, maybe you can take a look and point me in the right direction?
Attachment #8854159 -
Flags: feedback?(nicolas.b.pierron)
Assignee | ||
Updated•7 years ago
|
Attachment #8854159 -
Attachment is patch: true
Assignee | ||
Comment 1•7 years ago
|
||
Attachment #8854159 -
Attachment is obsolete: true
Attachment #8854159 -
Flags: feedback?(nicolas.b.pierron)
Assignee | ||
Updated•7 years ago
|
Attachment #8854160 -
Flags: feedback?(nicolas.b.pierron)
Assignee | ||
Comment 2•7 years ago
|
||
Assignee: nobody → evilpies
Comment 3•7 years ago
|
||
You also have to handle this instruction in ScalarReplacement in ScalarReplacement.cpp I think? Search for `CreateThisWithTemplate` for instance.
Assignee | ||
Comment 4•7 years ago
|
||
This works on the destructuring benchmark and improves our time from 30ms to 10ms \o/. Thanks for the tip Jan! I will look into writing some tests for this with assertRecoveredOnBailout.
Attachment #8854160 -
Attachment is obsolete: true
Attachment #8854160 -
Flags: feedback?(nicolas.b.pierron)
Assignee | ||
Comment 5•7 years ago
|
||
Try looks good enough: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ca9d874120bf968a8ec27074e5484e71cec72c48 This is hard to test: array[Symbol.iterator]() might not be inlined, so we can't use scalar replacement. destructuring and for-of don't expose the iterator. I am not sure yet if this is going to work with for-of, often we fail to do because of OSR (I think), the object is being leaked by a PHI instruction.
Attachment #8854373 -
Attachment is obsolete: true
Attachment #8854590 -
Flags: review?(jdemooij)
Comment 6•7 years ago
|
||
Comment on attachment 8854590 [details] [diff] [review] Implement scalar replacement for NewArrayIterator Review of attachment 8854590 [details] [diff] [review]: ----------------------------------------------------------------- Great results! ::: js/src/jit/Recover.h @@ +596,5 @@ > > +class RNewArrayIterator final : public RInstruction > +{ > + private: > + uint32_t count_; We can remove this field IIUC.
Attachment #8854590 -
Flags: review?(jdemooij) → review+
Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/df2d145e4c40 Implement scalar replacement for NewArrayIterator. r=jandem
Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/c2bb2f9f7dc3 disable the other assertRecoveredOnBailout as well.
Assignee | ||
Comment 9•7 years ago
|
||
I was hoping for a bigger wins on destructuring/for-of, but maybe we only inline everything that is needed later. Or maybe the PHI problem strikes again. I am going to file two followup ups: assertRecoveredOnBailout is hard to use and we should figure out the phi thing.
Updated•7 years ago
|
Flags: needinfo?(jdemooij)
Comment 10•7 years ago
|
||
The getSelfHostedValue version fails with --no-threads because we have an any-object typeset for the result of getSelfHostedValue. You can fix that by moving this line out of the function: var NewArrayIterator = getSelfHostedValue("NewArrayIterator"); With off-thread compilation the result depends on whether the main thread is faster than the compilation thread. The iterator test fails because of some code in ArrayIteratorNext: (1) The UnsafeSetReservedSlot if index >= len. This one we can probably fix by inlining better or by improving branch pruning heuristics? (2) The CallArrayIteratorMethodIfWrapped call. We should know |!IsObject(this) || !IsArrayIterator(this)| is always false so we should be able to optimize/prune this somehow. Maybe we can check if removing these branches helps sixspeed.
Flags: needinfo?(jdemooij)
Updated•7 years ago
|
Priority: -- → P3
Comment 11•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/df2d145e4c40 https://hg.mozilla.org/mozilla-central/rev/c2bb2f9f7dc3
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in
before you can comment on or make changes to this bug.
Description
•