This renames:
HeapSize::gcBytes -> bytes (it's not just for GC heaps any more)
ZoneThreshold -> HeapThreshold (to go with HeapSize)
HeapThreshold::triggerBytes -> bytes (what else could it be?)
I renamed the ZoneAllocator members to make them more uniform/consitent so we now have gcHeapSize/gcHeapThreshold, mallocHeapSize/mallocHeapThreshold etc.
I also renamed the heap threshold classes.
Differential Revision: https://phabricator.services.mozilla.com/D42868
--HG--
extra : moz-landing-system : lando
The final huge patch. This is a search-and-replace removal of js::Class followed by clang-format and removal of the alias from TypeDecls.h.
Depends on D41986
Differential Revision: https://phabricator.services.mozilla.com/D41987
--HG--
extra : moz-landing-system : lando
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
Another big patch. This a search-and-replace followed by mach clang-format, and removal of the js::ClassOps alias from Class.h.
Differential Revision: https://phabricator.services.mozilla.com/D41761
--HG--
extra : moz-landing-system : lando
This removes the original js::ClassOps but leaves it aliased to JSClassOps so everything compiles for now.
Differential Revision: https://phabricator.services.mozilla.com/D41759
--HG--
extra : moz-landing-system : lando
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