Put them behind a MOZ_HASH_TABLE_CHECKS_ENABLED define, which right now is only
defined in DEBUG builds, preserving behavior.
MakeImmutable becomes an empty inline function when disabled, which should be
zero-cost.
Differential Revision: https://phabricator.services.mozilla.com/D50493
--HG--
extra : moz-landing-system : lando
Default constructors of members run if not specified there, and these ifdefs
are ugly.
Differential Revision: https://phabricator.services.mozilla.com/D50492
--HG--
extra : moz-landing-system : lando
I want to maybe enable some of these checks in DIAGNOSTIC_ASSERT builds.
The whole type is compiled out in release builds at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D50491
--HG--
extra : moz-landing-system : lando
This replaces a direct call of an object's finalizer with a more formal API. This adds some assertions and passes a valid FreeOp pointer to the finalizer rather than null.
Differential Revision: https://phabricator.services.mozilla.com/D50571
--HG--
extra : moz-landing-system : lando
This renames the JSStringFinalizer struct to JSExternalStringCallbacks,
makes it a virtual class, and adds a size-of callback to it (to replace
the per-runtime callback).
This will make it possible to implement this callback easily for the
NewExternalString testing function (which we want for bug 1590641)
without having to move this testing function to shell/js.cpp
Differential Revision: https://phabricator.services.mozilla.com/D50234
--HG--
extra : moz-landing-system : lando
We could try to move the EnforcePendingTaskGuarantee() bit into
PeekIdleDeadline, but then we'd need to check HasReadyEvent() on
mDeferredTimersQueue and mIdleQueue before we possibly unlock the mutex under
PeekIdleDeadline, and it's not clear that that state cannot change once the
mutex is unlocked...
The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.
Differential Revision: https://phabricator.services.mozilla.com/D49696
--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
extra : moz-landing-system : lando
Today I reviewed wrong usage of this API.
It'd be good if it crashed in debug builds when misused.
Differential Revision: https://phabricator.services.mozilla.com/D49778
--HG--
extra : moz-landing-system : lando
We could try to move the EnforcePendingTaskGuarantee() bit into PeekIdleDeadline, but
then we'd need to check HasReadyEvent() on mDeferredTimersQueue and mIdleQueue
before we unlock the mutex and PeekIdleDeadline, and it's not clear that that
state cannot change once the mutex is unlocked...
The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.
Differential Revision: https://phabricator.services.mozilla.com/D49696
--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
This method turned out to only be used for tracing wrapper cached things. The wrapper cache has its own way of implementing barriers and contains a raw JSObject pointer. Changing this trace method to take an nsWrapperCache pointer (effectively a JSObjct**) enforces correct use of Heap<T> for other TraceCallbacks callers.
Differential Revision: https://phabricator.services.mozilla.com/D48693
--HG--
extra : moz-landing-system : lando
This was disabled in Bug 1441558 because it broke the mingw-gcc build.
But it doesn't break the mingw-clang build, and we don't support mingw-gcc
anymore, so we can re-enable it.
Differential Revision: https://phabricator.services.mozilla.com/D48645
--HG--
extra : moz-landing-system : lando
People keep shooting themselves in the feet because of this codepath and writing
slow code.
There are just a few elements with bindings left, so just check those.
Also simplify a bit the code. The XUL element + tagname check should be pretty
fast now, and ComputedStyle objects no longer keep weak pointers to pres
contexts and such, so can be safely kept on a RefPtr across an style flush.
Differential Revision: https://phabricator.services.mozilla.com/D47995
--HG--
extra : moz-landing-system : lando
This includes some annotations to isOverridableField() that are only necessary at this point in the patch stack; the entire function will be removed shortly.
Differential Revision: https://phabricator.services.mozilla.com/D46565
--HG--
extra : moz-landing-system : lando
This function is needed for people whose needs don't map cleanly to
`NS_DispatchToBackgroundThread`, usually because they're using the event
target to do thread consistency checks. Once we have this function, we
can start converting singleton threads/thread pools that want to use
functionality like the above.
Differential Revision: https://phabricator.services.mozilla.com/D47454
--HG--
extra : moz-landing-system : lando
Eventually, we're going to want to hand out an `nsIEventTarget*` to people
wanting to dispatch to background threads, but for whatever reason not
wanting to use the `NS_DispatchToBackgroundThread` API (probably because
they want to verify correctness by checking that certain methods are, in
fact, running on the background event target). And because we're going to
want to have some sort of division between CPU-bound and IO-bound tasks, we
can't just hand out references to a single thread pool. We need some sort
of intermediate object for both of these goals, and that is what the added
`BackgroundEventTarget` class is.
Differential Revision: https://phabricator.services.mozilla.com/D47343
--HG--
extra : moz-landing-system : lando
It's fairly common for clients to hold a pointer to some private thread
and then inquire about `IsOnCurrentThread` in debug checks. As we
migrate these private threads into some `nsIEventTarget` implementation
that might be running on thread pools, we need to ensure that those
`IsOnCurrentThread` continues to be relatively cheap. The current
implementation for thread pools is not particularly efficient.
The inefficiency comes from having to iterate over all the threads in
the pool. But there's no need to do this; we can just have each thread
set a particular thread-local variable to the thread pool it's running
on, and check the value of that thread-local variable instead.
Differential Revision: https://phabricator.services.mozilla.com/D47139
--HG--
extra : moz-landing-system : lando
We have a number of people starting up singleton threads for the sole
purpose of running a single runnable on them. These consumers often
leave the thread running until some point close to shutdown, or they
never shut it down at all. Let's add a helper function to do the thing
they actually want to do, and then we can modify the implementation of
that function as necessary as we merge singleton threads (and even
thread pools) together.
Differential Revision: https://phabricator.services.mozilla.com/D46997
--HG--
extra : moz-landing-system : lando
To remove the blocking inside nsThread::Init, two things needed
to happen:
- Switch the ThreadInitData value passed as the argument for
ThreadFunc to a heap allocation, so that it can outlive the call
to nsThread::Init.
- Initialize mThread and mEventTarget->mThread to the return
value of PR_CreateThread, so that to the callers, checks which
depend on these values being set can continue to function.
Differential Revision: https://phabricator.services.mozilla.com/D41248
--HG--
extra : moz-landing-system : lando
GetCurrentPhysicalThread and GetCurrentVirtualThread are, in practice,
identical, as the TLS override that GetCurrentVirtualThread depends on
is never actually set. This simply removes that and renames some things/
deletes some comments.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
NS_ERROR_DOM_TYPE_ERR is not much better, but this at least allows us to get
rid of NS_ERROR_TYPE_ERR completely...
Differential Revision: https://phabricator.services.mozilla.com/D46485
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D46642
--HG--
extra : moz-landing-system : lando
The two remaining consumers don't seem to depend on actually using this
specific nsresult in any way.
Differential Revision: https://phabricator.services.mozilla.com/D46462
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Fix handling of ABI arguments in xptcinvoke for PPC64 platforms. Previously, non-floating-point arguments would advance the index of which floating-point register to use. This cleans up both of the platform-specific invoke and stubs to be better aligned to the x86_64 model.
Differential Revision: https://phabricator.services.mozilla.com/D46421
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
mAboutToBeNotifiedRejectedPromises will be clear in AfterProcessMicrotasks()
and mPendingUnhandledRejections will be clear after NotifyUnhandledRejections
runnable is handled.
However, worker could terminate in any time, we still need to clear those
structures manually before CollectData is clear.
Differential Revision: https://phabricator.services.mozilla.com/D46095
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
This also removes a dependency on rand 0.4 getting it closer to being
able to remove that.
Differential Revision: https://phabricator.services.mozilla.com/D45710
--HG--
extra : moz-landing-system : lando
This reverts the available memory tracker back to its old implementation that
relied on GlobalMemoryStatusEx() instead of the potentially expensive
K32GetPerformanceInfo(). In spite of its name GlobalMemoryStatusEx() may return
per-process values instead of global ones which might lead to underestimating
the actual memory pressure. Because of this limitation this change is a
stop-gap while we replace this code with a non-polling implementation based on
QueryMemoryResourceNotification().
Differential Revision: https://phabricator.services.mozilla.com/D45338
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
This matches the requirement imposed by the Container concept that its iterator type
should be convertible to its const_iterator type.
Differential Revision: https://phabricator.services.mozilla.com/D44673
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
Compilers have gotten a lot better since the last time we tried this, and the
generated SIMD code for the inlined memcmp is more efficient than our manual
comparison operations.
Differential Revision: https://phabricator.services.mozilla.com/D43802
--HG--
extra : moz-landing-system : lando
Note that this code asserts it gets run in the parent process, so we can be sure that we never
want the content process sandbox-accessible dir or similar (though tbf, that seems odd given
we have DOM machinery to proxy from the child to here... but that's what happens today).
This will start using the actual temp dir even in the case of e.g. xpcshell, which normally
dependency-injects a different (also temp) dir and reuses it as the profile as well as temp
dir ( https://searchfox.org/mozilla-central/rev/03853a6e87c4a9405fce1de49e5d03b9e7a7a274/testing/xpcshell/head.js#1207-1226 )
if and only if anything calls do_get_profile .
I think this is likely OK... but if not, we'll have to come up with a more complicated
solution...
Differential Revision: https://phabricator.services.mozilla.com/D42950
--HG--
extra : moz-landing-system : lando
Whereas previously MozDescribeCodeAddress would have handled demangling,
we need to explicitly do that from our new GetFunction method. The string we
generate is now more useful for the profiler to merge -- having dropped the
address in the previous patch, and the file & line number and library in this
patch.
While we're at it, try to demangle Rust symbols too.
Ideally we'd add Rust symbol handling to DemangleSymbol in
StackWalk.cpp, but that lives in mozglue, which currently cannot have
any Rust crate dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D43142
--HG--
extra : moz-landing-system : lando
Christoph Kerschbaumer
Kirk Steuber
Boris Zbarsky
Emma Malysz
Martin Stransky
Emilio Cobos Álvarez
Jan de Mooij
Ehsan Akhgari
Andreea Pavel
Jon Coppeard
Alex Henrie
Mihai Alexandru Michis
Tim Nguyen
Narcis Beleuzu
Andrea Marchesini
Sebastian Hengst
Dorel Luca
ffxbld
Cosmin Sabou
Olli Pettay
Andrew Halberstadt
Tom Ritter
Ricky Stewart
Daniel Varga
Sylvestre Ledru
Paul Bone
Simon Giesecke
Bogdan Tara
Steve Fink
Oana Pop Rus
Gabriele Svelto
Nathan Froyd
Brian Hackett
Josh Aas
Doug Thayer
kriswright
Geoff Brown
Jean-Yves Avenard
arthur.iakab
Edgar Chen
Cameron Kaiser
Henri Sivonen
Gerald Squelart
Gijs Kruitbosch
Bastien Orivel
Chris H-C
Benjamin
Razvan Maries
Tom Ritter
Christian Holler
Coroiu Cristina
John Dai
Gurzau Raul
Nika Layzell
Csoregi Natalia
Paul Zuehlcke
Kris Maglione
Mirko Brodesser
Honza Bambas
Cameron McCormack
Mike Hommey
Maliha Islam
Robert Strong
Hiroyuki Ikezoe