Change storage for private methods to save space
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox90 | --- | fixed |
People
(Reporter: mgaudet, Assigned: jorendorff)
References
(Blocks 1 open bug, Regressed 2 open bugs)
Details
Attachments
(20 files, 5 obsolete 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 | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1662559 - Part 12: Modify effectiveScopePrivateFieldCache to store NameLocations as well. r=arai
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Currently the storage of private methods means that every private method is treated like a field on an object.
This can be improved.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
The new class is not actually used yet; see the next patch.
Depends on D108283
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D108284
Assignee | ||
Comment 4•4 years ago
|
||
Depends on D108285
Assignee | ||
Comment 5•4 years ago
|
||
It is a copy of BlockLexicalEnvironmentObject. Note that
-
ClassBodyScope is not a LexicalScope, BUT
-
ClassBodyLexicalEnvironmentObject is a LexicalEnvironmentObject
This is strictly a matter of how much implementation is shared. The word
"Lexical" in LexicalEnvironmentObject, and to some extent throughout
SpiderMonkey, is alas already pretty meaningless. In the language
specification, all environments are lexical environments.
Depends on D108286
Assignee | ||
Comment 6•4 years ago
|
||
Depends on D108287
Assignee | ||
Comment 7•4 years ago
|
||
Not every class gets this special binding. It will be needed for all classes
that have any nonstatic private methods, getters, or setters. With this patch,
we create a .privateBrand binding in the scopes for such classes, and populate
it with a symbol when initializing the class. However, it is not yet being used
anywhere; the constructor does not yet stamp instances with the private brand.
Depends on D108288
Assignee | ||
Comment 8•4 years ago
|
||
This adds a hasPrivateBrand bit to the MemberInitializers struct in the
stencil. It is necessary to persist this bit across compilation units because
emitInitializeInstanceMembers can be called in direct eval code inside a
derived-class constructor.
Since .privateBrand is currently a let
binding, this currently emits an
unnecessary CheckAliasedLexical instruction in the constructor for each class
that has nonstatic private methods. We'll eliminate these later on.
Depends on D108289
Assignee | ||
Comment 9•4 years ago
|
||
This is currently used only by the bindings in a ClassBodyScope.
The behavior of these bindings is like Var bindings. There is no longer a TDZ
check, and we don't bother marking them as Uninitialized. So the special case
introduced in bug 1683746, peeking at the binding name to see if we should skip
the TDZ check, is no longer needed.
Depends on D108290
Assignee | ||
Comment 10•4 years ago
|
||
This is how the frontend will later identify private methods in order to emit
special bytecode.
Depends on D108291
Assignee | ||
Comment 11•4 years ago
|
||
This affects bytecode, as Synthetic bindings do not get TDZ checks.
This patch also tightens up some assertions when creating ScopeData. There are
several methods that create ScopeData, and they had gotten out of sync. The
assertions check that the ScopeData is not silently dropping bindings that were
present in ParseContext::Scope::declared_.
Depends on D108292
Assignee | ||
Comment 12•4 years ago
|
||
This would cause private methods to be marked as such on scopes, except that
the parser still declares them as DeclarationKind::Synthetic
for now.
Depends on D108293
Assignee | ||
Comment 13•4 years ago
|
||
Depends on D108294
Assignee | ||
Comment 14•4 years ago
|
||
The diff is a mess, but this is very straightforward--we have a combination of
if-statements and a switch that could just be a single switch.
Depends on D108295
Assignee | ||
Comment 15•4 years ago
|
||
The new parse nodes then need to be handled throughout the BytecodeEmitter. No
change in behavior.
Depends on D108296
Assignee | ||
Comment 16•4 years ago
|
||
Depends on D108297
Assignee | ||
Comment 17•4 years ago
|
||
Depends on D108298
Assignee | ||
Comment 18•4 years ago
|
||
Depends on D108299
Assignee | ||
Comment 19•4 years ago
|
||
At the same time, the initialization and storage of private methods is changed
to what the PrivateOpEmitter expects.
There are some barely-observable differences in behavior, resulting in two jit-test changes:
-
fields/bug1683784.js - An error message changed. Not really better or worse.
-
js/src/jit-test/tests/parser/script-source-extent.js - The debugger is able
to observe initializers as individual scripts. We are no longer using
initializers for private methods that can be optimized, and the debugger
therefore observes the change. I adjusted the test to expect the new
behavior.
Two jit-tests fail:
-
fields/private-eval-in-frame.js - The very dynamic scopes in which
Frame.prototype.eval runs do not pass through static information about
private methods, so an assertion in lookupPrivate fails. One possible
workaround would be to ban the use of private fields and methods in
eval-in-frame code. -
debug/private-methods-eval-in-frame.js - Same.
All js/src/tests pass.
Depends on D108300
Assignee | ||
Comment 20•4 years ago
|
||
Depends on D108301
Assignee | ||
Comment 21•4 years ago
|
||
And here's a Try run with failures in the two tests mentioned in comment 19.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 22•4 years ago
|
||
By storing NameLocations we also get a BindingKind, which allows us to disambiguate between
PrivateMethods and Synthetics.
Depends on D108295
Reporter | ||
Comment 23•4 years ago
|
||
In order to correctly support this with the optimized storage for methods we
would need new bytecode like GetAliasedVar which is able to traverse
non-EnvironmentObject environments like DebugEnvironmentProxy.
Depends on D109401
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 24•4 years ago
|
||
Comment 25•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/88203b6f2e5a
https://hg.mozilla.org/mozilla-central/rev/8970e82f0312
https://hg.mozilla.org/mozilla-central/rev/547e0b38d66e
https://hg.mozilla.org/mozilla-central/rev/ae45d407929f
https://hg.mozilla.org/mozilla-central/rev/e200366e7e3a
https://hg.mozilla.org/mozilla-central/rev/0b01a60bb702
https://hg.mozilla.org/mozilla-central/rev/3902d4cb84cc
https://hg.mozilla.org/mozilla-central/rev/70d767bf04ad
https://hg.mozilla.org/mozilla-central/rev/1420d94f0d59
https://hg.mozilla.org/mozilla-central/rev/0b14a97cd0fb
https://hg.mozilla.org/mozilla-central/rev/1bac4e440311
https://hg.mozilla.org/mozilla-central/rev/0f5bcb3ca09f
https://hg.mozilla.org/mozilla-central/rev/118b19a448fa
https://hg.mozilla.org/mozilla-central/rev/cc3a2fadee36
https://hg.mozilla.org/mozilla-central/rev/405a80f38f5c
https://hg.mozilla.org/mozilla-central/rev/be3069057f5a
https://hg.mozilla.org/mozilla-central/rev/bd328ac14770
https://hg.mozilla.org/mozilla-central/rev/5e4ca6c62d4b
https://hg.mozilla.org/mozilla-central/rev/0fbfd31e0f78
https://hg.mozilla.org/mozilla-central/rev/4c69d3aabee4
Comment 26•4 years ago
|
||
Backed out for fuzzing failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/a0de4a88ac294b26a83f3776bb110d53405bde6a
Comment 27•4 years ago
|
||
Backout merged: https://hg.mozilla.org/mozilla-central/rev/a0de4a88ac29
Reporter | ||
Comment 28•4 years ago
|
||
(This will be rolled into Part 4 for landing)
Reporter | ||
Comment 29•4 years ago
|
||
The intention of the Patch stack, among other things, is to separate the
handling of regular lexical bindings from those that are synthetic and private
methods; things never exposed to or handled in script. As a result of this
divergence, a case in the NameOpEmitter was missed: here we emit SetLocal
instead of the expected InitializeLexical (well, as expected as can be without
thinking about a potentially more accurate bytecode called
InitializeSyntheticOrPrivate)
We also handle EnvironmentCoordinates in the same way
This will be rolled into Part 9 for landing.
Depends on D108293
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 30•4 years ago
|
||
This will be rolled into Part 19 for landing.
Note: This is the fixup patch I am least comfortable with. I am open to the
suggestion that maybe the -correct- action here is to break apart
PrivateOpEmitter::emitGet(), which appears to have far too complex a semantics
to reason about.
Depends on D108301
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 31•4 years ago
|
||
Comment 32•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/86392a2f9d18
https://hg.mozilla.org/mozilla-central/rev/a7ffffabe660
https://hg.mozilla.org/mozilla-central/rev/235c9126589a
https://hg.mozilla.org/mozilla-central/rev/d3b226ecc677
https://hg.mozilla.org/mozilla-central/rev/dd28bf5beaf8
https://hg.mozilla.org/mozilla-central/rev/5ce850a6e268
https://hg.mozilla.org/mozilla-central/rev/0954e98760d0
https://hg.mozilla.org/mozilla-central/rev/58e84f08f369
https://hg.mozilla.org/mozilla-central/rev/7045f0aa9352
https://hg.mozilla.org/mozilla-central/rev/fafe4be45090
https://hg.mozilla.org/mozilla-central/rev/462358e96220
https://hg.mozilla.org/mozilla-central/rev/2ae9723b04dc
https://hg.mozilla.org/mozilla-central/rev/686e81e46bfb
https://hg.mozilla.org/mozilla-central/rev/4082f63c554a
https://hg.mozilla.org/mozilla-central/rev/75ca82a2e26a
https://hg.mozilla.org/mozilla-central/rev/8dd759f91922
https://hg.mozilla.org/mozilla-central/rev/051adeafc417
https://hg.mozilla.org/mozilla-central/rev/a48c2c09a753
https://hg.mozilla.org/mozilla-central/rev/c4c9cea546f9
https://hg.mozilla.org/mozilla-central/rev/bc1d34f55b6b
Description
•