In bug 1537609 we capped our main thread stack quota to 2 MB on Windows because
larger stacks can make some broken websites terribly slow. However on Linux and
Mac we still had larger stack sizes. Having significant differences in behavior
across platforms isn't great and it means those "broken" websites are still slow
on Mac/Linux, see bug 1562700 for example.
This patch adds a stack-quota-cap pref and applies it on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D44441
--HG--
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
Also closes bug 1576216: update ZoneStats and RealmStats memory
accounting for this change.
Differential Revision: https://phabricator.services.mozilla.com/D42977
--HG--
extra : moz-landing-system : lando
This commit is the boilerplate for making WASM_HUGE_MEMORY a runtime decision.
Because WasmModule's can be passed across threads with `postMessage`, we need
to make this decision once per process. The support for this kind of flag seems
ad-hoc, so I stubbed in a global flag in WasmProcess.
A new 'javascript.options.wasm_disable_huge_memory' pref and
'--disable-wasm-huge-memory' JS shell flag are added. These have no effect if
the current platform doesn't support huge memory.
Tests and fuzzing flags are modified to also test with these new flags.
Differential Revision: https://phabricator.services.mozilla.com/D41866
--HG--
extra : moz-landing-system : lando
This commit is the boilerplate for making WASM_HUGE_MEMORY a runtime decision.
Because WasmModule's can be passed across threads with `postMessage`, we need
to make this decision once per process. The support for this kind of flag seems
ad-hoc, so I stubbed in a global flag in WasmProcess.
A new 'javascript.options.wasm_disable_huge_memory' pref and
'--disable-wasm-huge-memory' JS shell flag are added. These have no effect if
the current platform doesn't support huge memory.
Tests and fuzzing flags are modified to also test with these new flags.
Differential Revision: https://phabricator.services.mozilla.com/D41866
--HG--
extra : moz-landing-system : lando
If either the Realm or the request needs full-parsing, we disable lazy
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D42560
--HG--
extra : moz-landing-system : lando
We already have an accessor to make sure this is can only be set but not
cleared so hide the underlying storage.
Differential Revision: https://phabricator.services.mozilla.com/D42559
--HG--
extra : moz-landing-system : lando
If either the Realm or the request needs full-parsing, we disable lazy
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D42560
--HG--
extra : moz-landing-system : lando
This patch restores the order of the slow script checks in
XPJSContext::InterruptScript to avoid filling our logs with useless warnings
in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D42587
--HG--
extra : moz-landing-system : lando
One problem with using shared memory instead of files for MemMapSnapshot
is that AutoMemMap was trying to use fstat() to obtain the object size;
that doesn't work with ashmem on Android and was causing problems with
the Mac sandbox, but it's not necessary, because we already know the
size. This patch changes it to not do that.
Depends on D26743
Differential Revision: https://phabricator.services.mozilla.com/D26744
--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
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
This patch cleans up remote outer window proxies when we navigate back
into the process.
It adds a flag to mDanglingRemoteOuterProxies that is set in between
BrowsingContext::SetDocShell(), where we can tell that the browsing
context is going from being remote to being local, to
nsGlobalWindowOuter::SetNewDocument(), where the local outer window
proxy is actually created. Once the outer window is created, the
remote window proxies can be cleaned up in
CleanUpDanglingRemoteOuterWindowProxies().
The clean up is done by a process that is similar to object
transplanting, except that instead of looking in the cross-compartment
wrapper table for each compartment to find objects to be turned into
CCWs to the new object, it looks in the remote proxy map for each
compartment. SpiderMonkey doesn't know about the proxy maps, so this
has to be done by a new callback object CompartmentTransplantCallback.
Now that this cleanup is being done, it shouldn't be possible to wrap
a remote outer window proxy when the browsing context is local, so
MaybeWrapWindowProxy() can be simplified. I had to drop the assert
here that the browsing context has a window proxy because during clean
up we call wrap on a local outer window proxy before the BC gets the
window proxy set on it. I had the assert because my original plan was
to implicitly fix remote proxies during wrapping, but that is no
longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D38343
--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
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
These tests both load a page, create some chrome reference to it, then
navigate to another page to cause a window close on the original page,
then check to make sure the references to the original page have gone
away.
With Fission, if the navigation is cross-process, then the message
manager gets torn down in the original process where the browser test
is running, and the sendAsyncMessage call in content-task.js fails
with the cryptic error NS_ERROR_ILLEGAL_VALUE.
This can be fixed by making the navigation not be cross-origin. The
test only wants the original pages to be torn down. The origin of the
new page doesn't matter.
Differential Revision: https://phabricator.services.mozilla.com/D41408
--HG--
extra : moz-landing-system : lando
This could be made into a static pref, but then it would be always defined and
thus visible in about:config, which seems undesirable for such a senstive pre.
So this patch uses a callback that makes it work just like the existing
VarCache, i.e. it's not defined by default, in which case it defaults to false.
Differential Revision: https://phabricator.services.mozilla.com/D40343
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
