On Linux and Android, both jitdump and the marker file will keep using
`CLOCK_MONOTONIC` nanoseconds, as before.
On macOS, both jitdump and the marker file will now be using
`TimeStamp::RawMachAbsoluteTimeNanoseconds()` , i.e. "nanoseconds since
mach_absolute_time origin".
This value has the advantage that it is also relatively easy to obtain
in other browser engines, because their internal timestamp value is stored
in milliseconds or nanoseconds rather than in `mach_absolute_time` ticks.
In the past, on macOS, Firefox was using `CLOCK_MONOTONIC` nanoseconds for
jitdump and `TimeStamp::RawMachAbsoluteTimeValue()` for the marker file.
This inconsistency is now fixed.
I will update samply to change how it treats jitdump timestamps on macOS.
There are no other consumers of jitdump files on macOS that I know of.
On Windows, we will keep using raw QPC values for the marker file - this
matches what's in the ETW events. Jitdump on Windows is mostly unused but
I'm updating it to match.
Furthermore, this fixes the order in mozglue/misc/moz.build to make sure
we always use the TimeStamp_darwin implementation on Darwin (and not just
due to a broken configure check, see bug 1681445), and it fixes the #ifdef
in TimeStamp.h to match the Darwin check.
Differential Revision: https://phabricator.services.mozilla.com/D199592
Basically we were falling off a cliff where if we had a bunch of marks recorded
with a particular name, when trying to measure we would fill an array with all
of them only to return the last one. This just replaces that by iterating in
reverse and returning the first matching mark. Arguably we should be using a
hashmap or something here, but this is a quick and trivial improvement that I
think will resolve the reported issue.
Differential Revision: https://phabricator.services.mozilla.com/D199451
This will allow ETW to collect the additional payload on the UserTiming markers. As well as allow the provider to filter on these markers in order to minimize overhead from other markers that don't need to be collected.
Differential Revision: https://phabricator.services.mozilla.com/D196332
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Currently these get output to the current working directory. On
Android, however, we cannot write to that directory, so this
environment variable can be used to set a directory that is writeable.
Differential Revision: https://phabricator.services.mozilla.com/D190289
Pending->Canceling->Killing (WorkerNeverRan)
Need to clear WorkerPrivate::mPreStartRunnables
Could we call WorkerRunnable::WorkerRun() to release resource? There could be no WorkerGlobalScope...
Pending->Running->Closing->Canceling->Killing(WorkerRan)
Pending->Running->Canceling->Killing(WorkerRan)
When entering “Closing”
1. Keeping receives normal WorkerRunnables
2. Making ParentStatus as Closing
3. Cancel all timeout
4. Don’t clear the main event queue anymore. But we still wait for all SyncLoops be completed.
5. Call WorkerGlobalScope::NoteTerminating() and nsIGlobalObject::DisconnectEventTargetObjects().
6. Switching to “Canceling” by asking parent thread to call WorkerPrivate::Cancel()
When entering “Canceling”
1. Call WorkerGlobalScope::NoteTerminating()
2. Notify StrongWorkerRefs, worker is in “Canceling”, send and complete the corresponding shutdown work right now.
3. Executing all runnables until no normal WorkerRunnables in queue and no WorkerRefs, SyncLoops and children workers
4. Stop receiving normal WorkerRunnables and DisconnectEventTargetObjects of WorkerScope.
4. Entering “Killing”
When entering “Killing”
1. We would not notify WorkerRefs anymore. Logically all WorkerRefs should be released in “Canceling”
2. Executing all remaining ControlRunnables
3. Release corresponding resources of Worker on worker thread.
Depends on D173850
Differential Revision: https://phabricator.services.mozilla.com/D177511
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
The System Principal boolean was only used for RFP purposes.
We replace it with an RTPCallerType and populate it not in
the Performance ctor but rather in the CreateFor methods
that will populate it based on the context of their
construction.
Depends on D151305
Differential Revision: https://phabricator.services.mozilla.com/D151306
This fixes the performance-measure-invalid.worker.html test. The test failed
because User Timing L3 section 4.2, "Convert a name to a timestamp", was not
implemented - the code was presumably residual from an earlier version of User
Timing. In particular, we never threw if the global object was not a Window. We
also corrected the code order for section 4.1, "Convert a mark to a timestamp",
which was incorrect but didn't cause any tests to fail.
Differential Revision: https://phabricator.services.mozilla.com/D154820
IsPerformanceTimingAttribute can be called by both Window and WorkerGlobalScope
global objects so we move it to the Performance* superclass.
Differential Revision: https://phabricator.services.mozilla.com/D154819
Root cause: the global object can be null but I wasn't checking for it so it
caused a crash. I don't remember under what conditions it can be null but I saw
I had checked for null when I wrote Performance::Mark and remember debugging it
so it makes sense to do so here as well.
Differential Revision: https://phabricator.services.mozilla.com/D151960
Root cause: the global object can be null but I wasn't checking for it so it
caused a crash. I don't remember under what conditions it can be null but I saw
I had checked for null when I wrote Performance::Mark and remember debugging it
so it makes sense to do so here as well.
Differential Revision: https://phabricator.services.mozilla.com/D151960
