Patch to report JS GC things that are live at shutdown as leaks by calling MOZ_LOG_CTOR for them. The JS engine now clears any remaining roots to prevent dangling pointers to freed memory after shutdown. I made XPCJSRuntime::Shutdown keep the weak pointer update callbacks as sometimes these tables have entries remaining at shutdown (if there are leaks) and we need the callbacks to update them.
This is looking more green on try now.
Differential Revision: https://phabricator.services.mozilla.com/D40449
--HG--
extra : moz-landing-system : lando
There are about the same number of occurrences of "ENABLE_INTL_API" and "EXPOSE_INTL_API"
in the tree, so preferring one over the other doesn't lead to fewer changes. Therefore
I went with "ENABLE_INTL_API", because "ENABLE_" (resp. "MOZ_ENABLE") is already used as
the prefix for other preprocessor ifdef's.
Differential Revision: https://phabricator.services.mozilla.com/D41188
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Introduces SweepingTracer and TraceWeakEdge to trace weak references in
AtomsTable::sweep and AtomsTable::sweepIncrementally while sweeping.
Also rename those two functions to traceWeak and traceWeakIncrementally.
Differential Revision: https://phabricator.services.mozilla.com/D40939
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Rather than make re-enabling the nursery work correctly (because there's
various ways to disable it and we'd need to make sure we're enabling it for
the right reason). It's simplier just to not disable it for a
gcMaxNurseryBytes of 0, and instead return an error.
Differential Revision: https://phabricator.services.mozilla.com/D39988
--HG--
extra : moz-landing-system : lando
This replaces the original JIT code memory counter with one that tracks the allocated JIT code precisely. This now uses a fixed threshold which was the original intention.
This also removes the INCREMENTAL_MALLOC_TRIGGER GC reason and all GCs triggered by malloc allocations use TOO_MUCH_MALLOC, so whether a GC is incremental is separated from the trigger reason.
Differential Revision: https://phabricator.services.mozilla.com/D39734
--HG--
extra : moz-landing-system : lando
This adds two new parameters. The growth fator is set to 1.5 and the base to 42MB. Trail and error showed that this latter value ended up triggering GCs roughtly in line with the old malloc counter. These values make the initial malloc threshold ~64MB.
Differential Revision: https://phabricator.services.mozilla.com/D39730
--HG--
extra : moz-landing-system : lando
Now that IonBuilder only depends on JitScript we no longer need to have a BaselineScript.
Differential Revision: https://phabricator.services.mozilla.com/D39168
--HG--
extra : moz-landing-system : lando
Avoid manual allocations and use default constructors when possible to
simplify code.
Differential Revision: https://phabricator.services.mozilla.com/D37946
--HG--
extra : moz-landing-system : lando
JS_TransplantObject is a very powerful API that results in the JITs
having to worry about the type of objects changing in surprising ways.
In practice though, there are very limited uses of this API so we can
add an API to determine which objects have to worry about transplanting.
This can then by asserted in JITs to document places that optimize
performance by expecting not to deal with transplants.
Differential Revision: https://phabricator.services.mozilla.com/D27975
--HG--
extra : moz-landing-system : lando
Also use default constructors when possible to remove duplications.
Depends on D37944
Differential Revision: https://phabricator.services.mozilla.com/D37945
--HG--
extra : moz-landing-system : lando
Replace HashMap<T>* with Maybe<HashMap<T>> in memory reporting to have
simpler code and better ergonimics.
Differential Revision: https://phabricator.services.mozilla.com/D37944
--HG--
extra : moz-landing-system : lando
Our previous representation of private values assumed that the private pointer was aligned, and did some bit twiddling to try to disguise it as a double. Since bug 1293313, it has been unnecessary to set the top bit for a double, so that bit twiddling is unnecessary. There are actual use cases where private values are unaligned, so we should fix this.
While cleaning this up, I also removed unboxPrivateValue, because its only use could be better written using loadPrivateValue directly.
Differential Revision: https://phabricator.services.mozilla.com/D38127
--HG--
extra : moz-landing-system : lando
Also reorder functions in OffThreadScriptCompilation to group by
data source type.
Differential Revision: https://phabricator.services.mozilla.com/D37575
--HG--
extra : moz-landing-system : lando
Because ShouldIncludeEdge considers the |origin| node as well, it was possible for
the old code to 'miss' nodes and never write them to the core dump even though we
also wrote some edges with the node as referent.
Differential Revision: https://phabricator.services.mozilla.com/D37701
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
Jon Coppeard
André Bargull
Oana Pop Rus
Steve Fink
Yoshi Cheng-Hao Huang
Andy Wingo
Razvan Maries
Coroiu Cristina
Andrew McCreight
Brindusan Cristian
Paul Bone
Tom Ritter
Jan de Mooij
Ciure Andrei
Iain Ireland
Jeff Walden
Ted Campbell
Brian Hackett
Boris Zbarsky
Greg Tatum