This requires --build-peers-said-large-imports-were-ok since
third_party/rust/mp4parse/src/lib.rs is 113KB. This code is just moving from
media/mp4parse-rust to third_party/rust, so it's not really adding to net code
size.
Differential Revision: https://phabricator.services.mozilla.com/D74488
This change simply changes line endings to make diffing easier with updates from OpenVR, which have Unix line endings.
Further, .clang-format-ignore, does not seem to work for wildcard to match a directory and subdirectory, so all files are listed individually.
Differential Revision: https://phabricator.services.mozilla.com/D74100
These defaults were per process and there are usually around 8 processes.
Now these sizes apply to all processes, so they can be 8 times as big (but less on Android where memory may be more limited.)
Not changing Base Profiler defaults, as its buffer is not cross-process controlled.
Differential Revision: https://phabricator.services.mozilla.com/D73215
This implement the child side:
When the first request for update arrives, it connects to the local chunk manager, to receive its updates.
If multiple updates are received, they are folded into one.
If there are both an update and a pending request, the request is fulfilled with the update and local data is reset.
And ProfilerChild handles "destroy" instructions to destroy local chunks.
At this point, the whole machinery is in place, and all combined profile buffers used in all processes should use around the maximum amount allowed.
A bit more memory may still be used, e.g., due to IPC delays, and because of recycling which keeps some unused chunks alive for later reuse. But overall that should be a small amount compared to the usual user-requested limit.
Differential Revision: https://phabricator.services.mozilla.com/D72369
The logic part of the controller receives all updates, and makes decisions to destroy old chunks when the memory limit is reached.
Differential Revision: https://phabricator.services.mozilla.com/D72368
When there is at least one ProfilerParent (i.e., we are interacting with at least one child process) AND the parent profiler is running, the ProfilerParentTracker sets up the ProfileBufferGlobalController that will manage all chunks.
As a first step, it connects with the local chunk manager (to receive chunk updates), and sends update requests to all children.
(The actual controller logic is not implemented in this patch, nor is the ProfilerChild side, see following patches.)
Differential Revision: https://phabricator.services.mozilla.com/D72367
The Gecko Profiler can notify the ProfilerParent when it's about to stop (if it was started, but the notification will happen even when it's not started).
Differential Revision: https://phabricator.services.mozilla.com/D72365
The Gecko Profiler can provide its current controlled chunk manager.
It is the responsibility of the caller to keep track of the state of the profiler, to avoid using the chunk manager after it's discarded.
Differential Revision: https://phabricator.services.mozilla.com/D72364
The defaults should serve our users. I did some profiling with mochitests
and the defaults weren't ideal. It would be nice if the profiler "just worked"
for most of the situations. It would be great to teach the environment variables
about presets, but for now this will make the profiler easier to use for our
users in the general case.
This patch adds both screenshots and updates the entries count. This causes
additional overhead, but people on low-end devices can still tweak the settings
to remove that overhead.
Differential Revision: https://phabricator.services.mozilla.com/D70091
The second example, when copied and pasted, is completely borked since it
is not preceeded by the line that declares what follows to be a Mermaid
diagram. This change fixes that.
It also fixes the prose to read slightly less awkwardly in places.
Finally, this change also adds a link to the Mermaid Live Editor to make
readers aware of this useful tool.
Differential Revision: https://phabricator.services.mozilla.com/D74338
Closer look at the man pages shows that the file() query will catch any file
changes, whereas the modifies() query will only capture files that were
modified, which excludes strict deletions.
Depends on D74065
Differential Revision: https://phabricator.services.mozilla.com/D74066
profiler_is_locked_on_current_thread() is used to help users avoid calling `profiler_...` functions when the profiler may already have a lock in place, which would prevent a 2nd recursive lock (resulting in a crash or a never-ending wait).
So we must return `true` for any of:
- The main profiler mutex, used by most functions, and/or
- The buffer mutex, used directly in some functions without locking the main mutex, e.g., marker-related functions.
Differential Revision: https://phabricator.services.mozilla.com/D73789
At the time this code was written, JavaScript JIT entry trampolines were
emitting EnterJIT label frames that carried a stack address. From this stack
address, register values could be recovered that would allow native stack
unwinding to resume after getting lost in JIT code.
The EnterJIT label frame was removed in bug 1057082.
Differential Revision: https://phabricator.services.mozilla.com/D73939
In rare cases, a dispatch may fail (e.g., threads are shutting down), we should handle this failure by rejecting the promise on the spot.
Depends on D73791
Differential Revision: https://phabricator.services.mozilla.com/D73792
It is not necessary to dispatch another task to the main thread to resolve/reject a MozPromiseHolder, because wherever this happens, the attached `Then` will do its own dispatch to the main thread.
Also, this removes a dispatch that could potentially fail, leaving the promise unfulfilled.
Depends on D73790
Differential Revision: https://phabricator.services.mozilla.com/D73791
While gathering profiles from child processes, some actions (e.g., shutting down, restarting the profiler) may reset the gathering operation.
In this case we must ensure that the promise is rejected if not already fulfilled, so that anyone waiting on it won't be blocked forever (and MozPromise enforces it in a MOZ_DIAGNOSTIC_ASSERT).
Differential Revision: https://phabricator.services.mozilla.com/D73790
Code should be using `throw Components.Exception("", Cr.ERROR);` instead,
since `new Error()` just converts the int value of the Cr.ERROR into a string,
whereas `Exception` constructs an Exception object with the result property set
to the Cr.ERROR value, so other code can identify it.
Differential Revision: https://phabricator.services.mozilla.com/D28074
This rule is based on the ESLint built-in no-throw-literal. Cr.ERRORs are also
literals since they are just integers and so have all the same disadvantages of
no stack info.
TestInterfaceJS.js is explicitly testing handling of throwing raw Cr.ERRORs and
thus needs to stay.
Differential Revision: https://phabricator.services.mozilla.com/D28072
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
The profiler can be given any power of two, but there were no safety checks to ensure that the buffer had a minimum workable capacity (to hold at least 4 chunks, each capable of holding at least one stack sample), and also to prevent large buffers that could break the currently-supported 2GiB limit.
This fixes the issue with test_merged_stacks.js, which was requesting a too-small buffer. (This started when we switched to the chunk-based buffer, because the profiler was blindly using the provided number as maximum, and dividing that size by 4 for each chunk, which was not enough to hold a full sample in some builds.)
Differential Revision: https://phabricator.services.mozilla.com/D73212
This was an issue around "six" and "click", this thread sheds some light:
https://github.com/pallets/click/issues/564.
This issue was reproducible by having a local python 2 flask app with Flask==1.0.2, Werkzeug==0.14.1 and Click==7.0. Upon self-shutdown, the TypeError was raised.
Upgrading Click to 7.1.2 resolves this issue both in that separate "reproduce app" and here in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D73351
