This is a followup patch for removing Frame::tls.
Now, we are preserving caller's and callee's tls'es for all possible cross-instance calls in the previously allocated abi slots.
We also use preserved tls values to restore the caller's tls in Ion. Baseline doesn't need this because it restores the caller tls from its private stack slot after the call.
Differential Revision: https://phabricator.services.mozilla.com/D82888
We are going to remove Frame::tls and support trampolines for indirect calls, so we need to get rid of using Frame::tls.
In this and the followup patches I will iteratively remove all dependencies of Frame::tls and remove it eventually.
In this patch I changed wasm ABI to allocate two stack slots after stack args to preserve caller's and callee's tls'es in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D82881
Contrary to python2, python3 considers the values in cl_lnotab to be signed
integers, so with python3, offsets larger than 127 would be encoded in a way
that would make them wrong, or worse, negative.
Differential Revision: https://phabricator.services.mozilla.com/D86122
Also modernize it a tiny bit. This also adjusts the conditions under which
the test is run, and keeps it disabled on CI for now since it's not clear
this will provide value from being run in CI at the moment (fails a lot).
Differential Revision: https://phabricator.services.mozilla.com/D86017
This moves the IPC mechanism from PCompositorBridge to PLayerTransaction/
PWebRenderBridge, so that it can be used by content processes like the other
test APIs. It still only produces actual data for the layers backend; for
WR it will just return empty datasets.
Differential Revision: https://phabricator.services.mozilla.com/D86016
`MOZ_RELEASE_ASSERT(registeredThread == TLSRegisteredThread::RegisteredThread(lock));` is failing on Android, probably as a follow-up to bug 1651086, which allowed multiple registrations (to fix a problem with yet-unknown root cause).
This assertion is too broad to help find the issue because at this point:
- If `FindCurrentThreadRegisteredThread()` is not null, `TLSRegisteredThread::RegisteredThread()` should also not be null, and it should equal `FindCurrentThreadRegisteredThread()`, from the first succesful `profiler_register_thread()`.
- If `FindCurrentThreadRegisteredThread()` is null, `TLSRegisteredThread::RegisteredThread()` should be null as well, from the first `profiler_unregister_thread()`.
So this patch splits this assertion into multiple more targeted ones to check the above, and also some extra assertions after de-registration, to ensure that both `FindCurrentThreadRegisteredThread()` and `TLSRegisteredThread::RegisteredThread()` are null.
Differential Revision: https://phabricator.services.mozilla.com/D86118
This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
In bug1654045, we would stop controlling media once media reaches to the end. Considering some user might still want to control media by pressing media keys even if it has ended, so adding a pref to control this abilitiy.
Differential Revision: https://phabricator.services.mozilla.com/D85930
The deactivation timer introduces an uncertainty of when user can control media, but instead of removing that, I want to add a pref to control it and disable it by default because I can still think of some benefit of this ability.
Differential Revision: https://phabricator.services.mozilla.com/D85928
I've left the monitor disabled for now, so that we can have a smaller pushes for enabling and disabling it if needed. It should allow more fine grained control.
We may also want to include extracting the monitor tool from a github version instead, and also removing the assumption and it being forked from the parent, so that it's instead given a process ID to treat as the parent it should watch.
Differential Revision: https://phabricator.services.mozilla.com/D84374
When the worklet has already received the notification to shut down, there
will be no further notfication to release another global.
Differential Revision: https://phabricator.services.mozilla.com/D85975
The threading model described in the javadoc (ExoPlayer.java#92 in tree)
requires that the player is accessed from a single thread. However current
GeckoHlsPlayer implementation violates this rule and uses the player from
Gecko main thread and other media task queues. Introduce methods to execute
code asynchronously and synchronously for GeckoHlsPlayer to follows the rule.
Also add comments documenting thread usages for some instance variables and
assertions in the begining of methods that need to be on the player thread
to help debugging.
Differential Revision: https://phabricator.services.mozilla.com/D85668
This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
On Windows, with the double quotes, the command goes through the msys
shell, which then alters the command line such that empty arguments are
transformed into \ when they reach python.
With the single quotes, make invokes the command directly, without going
through the msys shell, and empty arguments are preserved.
Differential Revision: https://phabricator.services.mozilla.com/D86097
UpdateScrollbarPosition and ReflowFinished both use the scroll range for this. It usually doesn't matter, but the next patch will make it important.
Differential Revision: https://phabricator.services.mozilla.com/D85983
Dmitry Bezhetskov
Erik Nordin
Cosmin Sabou
Butkovits Atila
Mike Hommey
Botond Ballo
Itiel
Matt Woodrow
Karl Tomlinson
Kagami Sascha Rosylight
Matthew Noorenberghe
Severin
Kartikaya Gupta
Gerald Squelart
Chris Fallin
alwu
Simon Fraser
sotaro
John Lin
Sam Foster
Jan-Ivar Bruaroey
Emily McDonough
Timothy Nikkel
Punam Dahiya
Andreea Pavel
Dzmitry Malyshau
Geoff Brown