Don't assume XPCOM_MEM_BLOAT_LOG is a filename. XPCOM_MEM_BLOAT_LOG and XPCOM_MEM_LEAK_LOG can be set to a filename or "1" or "2" for logging to stdout and stderr respectively.
Set the debug write directory for XPCOM_MEM_LEAK_LOG in the same way we already to for XPCOM_MEM_BLOAT_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D27968
--HG--
extra : moz-landing-system : lando
- `Array.map` becomes `Array.from`
- Array copying via `Array.slice` becomes `Array.from`.
- `Array.forEach` that did not rely on closures becomes `for`-`of` loops.
- Anything else: `Array.X` becomes `Array.prototype.X`.
Complex cases:
dom/bindings/test/TestInterfaceJS.js and
dom/bindings/test/test_exception_options_from_jsimplemented.html
use `Array.indexOf` to generate an error with a specific error message.
Switched to `Array.prototype.forEach` to generate the same error.
js/src/jit-test/tests/basic/exception-column-number.js
In this test `Array.indexOf()` is used to generate an error. Since the
exact message doesn't matter, I switched to `Array.from()`.
Intentionally not changed:
editor/libeditor/tests/browserscope/lib/richtext/richtext/js/range.js
Did not modify because this is 3rd-party code and the code uses
feature detection as a fall back when Array generics are not used.
testing/talos/talos/tests/dromaeo/lib/mootools.js
Did not modify because mootools adds the `Array.slice` method to the
`Array` object.
Not changed because they check the implementation of Array generics:
js/src/jit-test/tests/basic/arrayNatives.js
js/src/jit-test/tests/basic/bug563243.js
js/src/jit-test/tests/basic/bug618853.js
js/src/jit-test/tests/basic/bug830967.js
js/src/jit-test/tests/jaeger/recompile/bug656753.js
js/src/jit-test/tests/self-hosting/alternate-static-and-instance-array-extras.js
js/src/tests/non262/Array/generics.js
js/src/tests/non262/Array/regress-415540.js
js/src/tests/non262/extensions/regress-355497.js
js/src/tests/non262/extensions/typedarray-set-neutering.js
Depends on D27802
Differential Revision: https://phabricator.services.mozilla.com/D27803
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : moz-landing-system : lando
This patch introduces an asynchronous XPCOM interface for the bits client added in Bug 1523417
Differential Revision: https://phabricator.services.mozilla.com/D25161
--HG--
extra : moz-landing-system : lando
I missed this intermittent when enabling Android gtests in bug 1318091. Disable
the failing test on Android only, to green up Android gtest.
Differential Revision: https://phabricator.services.mozilla.com/D27535
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
Our old approach was reading this into a region of unexecutable memory,
meaning when we actually loaded the library it needed to be loaded into
executable memory. This fixes that. I suspect that any gains we were
seeing previously were due to hardware effects.
Differential Revision: https://phabricator.services.mozilla.com/D26018
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
This is just to make it simpler to use PrefetchVirtualMemory in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D26016
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
Because not all static components are using the static registration yet,
we can end up in situations where a same component is registered
multiple times, which can have some unexpected consequences.
Interestingly enough, this change revealed that we did have static
registration in place for components that were kept under the old system
after bug 1478124 and bug 1524687.
There are also possibly some non-obvious things that can happen while
migrating the remaining components, like what happened to me while I
worked on @mozilla.org/widget/components;1 (see bug 1542214 comment 0).
Differential Revision: https://phabricator.services.mozilla.com/D26698
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
Whenever chrome JS code leaks, we leak the dynamic atom "[System
Principal]". This causes an assertion, which hangs the browser in
stack walking code for multiple minutes on OSX. As a bandaid, make
this atom static so it won't leak.
My first instinct is that it would make sense to use this new atom
directly in SystemPrincipal, but atoms are represented internally as a
kind of nsAString, but principal code uses nsACStrings, so you end up
with an extra conversion from 16-bit to 8-bit.
This atom is also going to be present in any process running chrome
JS, so this will save a little bit of memory.
Differential Revision: https://phabricator.services.mozilla.com/D26590
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : histedit_source : acdfd2357fd06551dff5286c6b7c56bd92dd347b
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
This is based on the `c_str` macro in `js/rust/src/heap.rs`, but
returns a `NulTerminatedCStr` type that can be cast to a pointer.
This commit also changes `ThreadPtrHolder::new` to take a
`NulTerminatedCStr`, and removes an unnecessary `RefPtr` reference in
`is_current_thread`.
Differential Revision: https://phabricator.services.mozilla.com/D26429
--HG--
extra : moz-landing-system : lando
If the environment variable MOZ_GC_LOG_SIZE is set, then GC logs will
include some extra data that indicates how much memory the GC thing
uses, including extra data hanging off of it. This can be used
calculate finer grained information about the memory usage of scripts.
Differential Revision: https://phabricator.services.mozilla.com/D25882
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
Andreea Pavel
Razvan Maries
Haik Aftandilian
Myk Melez
Rob Wu
Dave Townsend
Gurzau Raul
Gabriele Svelto
Ian Moody
Kirk Steuber
Geoff Brown
Olli Pettay
Doug Thayer
Henri Sivonen
Sylvestre Ledru
Cosmin Sabou
Cameron McCormack
Mike Hommey
Martin Stransky
Julian Descottes
Michael Froman
Andrew McCreight
Aaron Klotz
Lina Cambridge