Do BytecodeEmitter::emitDestructuringObjRestExclusionSet without emitting GC Objects
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: mgaudet, Assigned: anba)
References
Details
Attachments
(13 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
BytecodeEmitter::emitDestructuringObjRestExclusionSet has an optimization which involves allocating a JSObject and doing some analysis and mutation of the object during BCE, with the goal of emitting better bytecode.
This approach as written is incompatible with stencil and needs to be rethought.
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
One thing that would be worthwhile to do is to experiment with turning this optimization off (the problematic code is an optimization) and see what the impact is on performance.
Assignee | ||
Comment 2•5 years ago
|
||
Performance is at minimum 50% slower when JSOp::NewObject
isn't used and there's a higher impact when more properties are present in the exclusion set, for example at eight properties it was about twice as slow for me. I did a quick test to see if it's possible to use ObjLiteralCreationData
here and it seems to work just fine. Should I prepare a proper patch to switch emitDestructuringObjRestExclusionSet
to use ObjLiteralCreationData
?
Reporter | ||
Comment 3•5 years ago
|
||
If you have a prototype already, yes, absolutely.
You’re amazing!
Assignee | ||
Comment 4•5 years ago
|
||
The preceding JSOp::{Object,NewObject,NewObjectWithGroup,NewArrayCopyOnWrite}
opcode already performs the correct stack depth adjustment.
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
The standard convention is to omit a is<T>
test when it is directly followed
by as<T>
, because as<T>
is also testing for is<T>
.
Depends on D65768
Assignee | ||
Comment 6•5 years ago
|
||
Depends on D65769
Assignee | ||
Comment 7•5 years ago
|
||
We can directly return JS::Value
from InterpretObjLiteralValue instead of passing
it indirectly through a MutableHandleValue
.
Depends on D65771
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D65772
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D65773
Assignee | ||
Comment 10•5 years ago
|
||
Depends on D65774
Assignee | ||
Comment 11•5 years ago
|
||
Use the ObjLiteral writer for the destructuring rest exclusion set when all
property keys are simple atoms, i.e. ObjectPropertyName
or StringExpr
. Also
supports MutateProto
aka "proto", because "proto" doesn't have any
special meaning in object destructuring patterns. Number and BigInt property
keys stay unsupported for the fast-path and computed property names also need
to take the slow path, because their value isn't known at parse time.
Depends on D65775
Assignee | ||
Comment 12•5 years ago
|
||
Depends on D65776
Assignee | ||
Comment 13•5 years ago
|
||
Depends on D65777
Assignee | ||
Comment 14•5 years ago
|
||
After part 10 we no longer perform an in-place update from JSOp::NewInit
to
JSOp::NewObject
, so the extra operand space for JSOp::NewInit
isn't needed
anymore.
Depends on D65781
Assignee | ||
Comment 15•5 years ago
|
||
Depends on D65786
Assignee | ||
Comment 16•5 years ago
|
||
This case was missed in bug 1605835.
Depends on D65787
Comment 17•5 years ago
|
||
Comment 18•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7fb3fd9172c5
https://hg.mozilla.org/mozilla-central/rev/de425cf4b2ac
https://hg.mozilla.org/mozilla-central/rev/c5b5f5a316f2
https://hg.mozilla.org/mozilla-central/rev/bbccf2268360
https://hg.mozilla.org/mozilla-central/rev/b906552a9959
https://hg.mozilla.org/mozilla-central/rev/2b7d03a2ea2c
https://hg.mozilla.org/mozilla-central/rev/201ec4cf9a1e
https://hg.mozilla.org/mozilla-central/rev/e8579166fcbf
https://hg.mozilla.org/mozilla-central/rev/8b170b754a5b
https://hg.mozilla.org/mozilla-central/rev/44fe840e94ff
https://hg.mozilla.org/mozilla-central/rev/6c8fa3e00997
https://hg.mozilla.org/mozilla-central/rev/5e52daafbbed
https://hg.mozilla.org/mozilla-central/rev/9e1b60eda95f
Description
•