Closed
Bug 1466458
Opened 6 years ago
Closed 6 years ago
Refactor Realm::enterRealmDepth_ a bit
Categories
(Core :: JavaScript Engine, enhancement)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla62
Tracking | Status | |
---|---|---|
firefox62 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(2 files)
(deleted),
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
The JITs will be able to switch to a different same-compartment realm before a function call. We want this to be just a single |cx->realm_ = realm;| store, but AutoRealm currently also increments Realm::enterRealmDepth_ - we don't have to do that in JIT code but it's subtle and needs some comments and minor refactoring to make this more obvious.
Assignee | ||
Comment 2•6 years ago
|
||
This renames Realm::enterRealmDepth_ to Realm::enterRealmDepthIgnoringJit_, to make it more clear that it's only bumped for C++ AutoRealm and not for JIT code Realm entering. Fortunately, that's all we need: * enterRealmDepthIgnoringJit_ is sufficient for Realm::shouldTraceGlobal - when the JIT enters a different realm, there must be a frame/script/function on the stack for that realm and this will ensure the realm's global is traced anyway. * We don't relazify functions in realms that are active. Here I added a JSCompartment::hasEnteredRealm flag we set during GC - key here is that the JIT can only enter a *same-compartment* realm, so there must always be a realm for that compartment that has been entered from C++/AutoRealm. It's subtle, but I hope the comments and refactoring make it a bit clearer.
Attachment #8982990 -
Flags: review?(luke)
Updated•6 years ago
|
Attachment #8982987 -
Flags: review?(luke) → review+
Comment 3•6 years ago
|
||
Comment on attachment 8982990 [details] [diff] [review] Part 2 - Refactor Realm::enterRealmDepth_ to account for Realms entered from JIT code Review of attachment 8982990 [details] [diff] [review]: ----------------------------------------------------------------- Great analysis comments and factoring. Agreed. ::: js/src/vm/JSCompartment.h @@ +584,5 @@ > + // compartment. Note that (without a stack walk) we don't know exactly > + // *which* realms, because Realm::enterRealmDepthIgnoringJit_ does not > + // account for cross-Realm calls in JIT code updating cx->realm_. See also > + // the enterRealmDepthIgnoringJit_ comment. > + bool hasEnteredRealm = false; semi-pre-existing: I was wondering how a non-counter bool was maintained in the presence of reentrance but I see that this is computed per-GC. I was wondering if this field and the above two could be commented together in a block that says: these are only for temporary GC use and only meaningful at particular points in the GC (e.g., it seems like running a slice would make their meaning stale). (In theory, these fields could be removed, using an external HashSet or something, but that's a separate question.)
Attachment #8982990 -
Flags: review?(luke) → review+
Assignee | ||
Comment 4•6 years ago
|
||
(In reply to Luke Wagner [:luke] from comment #3) > semi-pre-existing: I was wondering how a non-counter bool was maintained in > the presence of reentrance but I see that this is computed per-GC. I was > wondering if this field and the above two could be commented together in a > block that says: these are only for temporary GC use and only meaningful at > particular points in the GC (e.g., it seems like running a slice would make > their meaning stale). What do you think about grouping them in a struct? Something like: class JSCompartment { ... public: struct { bool maybeLive = true; ... bool hasEnteredRealm = false; } flagsSetByGC; }; comp->flagsSetByGC.hasEnteredRealm might make it clearer these are set by the GC. Other names are gcFlags, gcState...
Flags: needinfo?(luke)
Comment 5•6 years ago
|
||
I really like that idea. gcState sgtm (I was going to suggest gcTemporalState, but the comments could speak to the temporality clearly enough).
Flags: needinfo?(luke)
Pushed by jandemooij@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b968ba27d88c part 1 - Remove JSContext::enterRealmDepth_. r=luke https://hg.mozilla.org/integration/mozilla-inbound/rev/60828108f4b8 part 2 - Refactor Realm::enterRealmDepth_ to account for Realms entered from JIT code. r=luke
Comment 7•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b968ba27d88c https://hg.mozilla.org/mozilla-central/rev/60828108f4b8
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox62:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in
before you can comment on or make changes to this bug.
Description
•