This is a large number of largely mechanical changes. When possible, the code
was called to directly call `.get()` instead, performing the assertions
manually. In many places PromiseFlatCString() calls were added to dynamically
copy the strings into null terminated buffers if the string was not null
terminated.
Differential Revision: https://phabricator.services.mozilla.com/D286158
QueryPerformanceCounter is considered both reliable and fast since the era of Windows 8, so we can make a huge jump here and move away from GetTickCount always.
This largely simplifies TimeStamp on Windows and brings it on-par in terms of the used data (8 Bytes instead of 24) with all other platforms.
We can eliminate every measured heuristic and rely just on the values given from QueryPerformanceFrequency to determine ticks per second and/or resolution.
For consumers of Now() nothing really changes, as for virtually all "normal" cases they were already seeing QPC values.
But we know at least from bug 1976975 that the old reliability heuristic would strike from time to time in CI and let us fall back to GTC.
There might be other time related weirdnesses in tests coming from that we are not aware of to be related.
Consumers of NowLoRes() will now see the same high resolution (as they do already on MacOS) and practically there is no more reason to use it on Windows.
This guarantees 100% comparability between low- and high-res timestamps, which previously may have led to problems, too.
Note that this will remove support for the MOZ_TIMESTAMP_MODE environment variable, too. There seems to be no usage or documentation of it, it was there probably just for testing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D269724
QueryPerformanceCounter is considered both reliable and fast since the era of Windows 8, so we can make a huge jump here and move away from GetTickCount always.
This largely simplifies TimeStamp on Windows and brings it on-par in terms of the used data (8 Bytes instead of 24) with all other platforms.
We can eliminate every measured heuristic and rely just on the values given from QueryPerformanceFrequency to determine ticks per second and/or resolution.
For consumers of Now() nothing really changes, as for virtually all "normal" cases they were already seeing QPC values.
But we know at least from bug 1976975 that the old reliability heuristic would strike from time to time in CI and let us fall back to GTC.
There might be other time related weirdnesses in tests coming from that we are not aware of to be related.
Consumers of NowLoRes() will now see the same high resolution (as they do already on MacOS) and practically there is no more reason to use it on Windows.
This guarantees 100% comparability between low- and high-res timestamps, which previously may have led to problems, too.
Note that this will remove support for the MOZ_TIMESTAMP_MODE environment variable, too. There seems to be no usage or documentation of it, it was there probably just for testing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D269724
Previously we were passing strings to the constructor for
PerformanceEntry types, but we don't need that since we know them for
sure during the compile time. It makes it easier to use the static
atoms, and they should be faster than the previous code.
Differential Revision: https://phabricator.services.mozilla.com/D268543
Previously, it was called DispatchBufferFullEvent confusingly, but it
actually dispatches an event called resourcetimingbufferfull.
Differential Revision: https://phabricator.services.mozilla.com/D268520
Previously, it was called BufferEvent confusingly, but it actually
handles the logic related to the resource timing buffer full event.
Differential Revision: https://phabricator.services.mozilla.com/D268519
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
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
Emilio Cobos Álvarez