It's more appropriate because the running times are only relevant to a profiling session.
And PreviousThreadRunningTimes can now be accessed through the ThreadRegistration (thanks to the ProfiledThreadData pointer added in the previous patch).
Since the threads' RunningTimes don't live in `PlatformData`, and because they are now implicitly cleared between profiling sessions (because `ProfiledThreadData`s get destroyed/recreated when stopping/starting the profiler), there is no need for an explicit `ClearRunningTimes()` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121964
Because ProfiledThreadData is always related to IsBeingProfiled, they are set and cleared together.
In particular, this is used to quickly guess that the thread is being profiled by reading the non-atomic mProfiledThreadData, rather than reading the slightly slower atomic mIsBeingProfiled.
Differential Revision: https://phabricator.services.mozilla.com/D121963
This is mostly a copy of the old PlatformData. That old PlatformData will be removed in a later patch, once it's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121959
This will help with replacing the old {,Racy}RegisteredThread with the new ThreadRegistration classes, while still being able to access the old classes (until they are not needed anymore).
Differential Revision: https://phabricator.services.mozilla.com/D121849
Now {,Racy}RegisteredThread don't contain any data, but provide the same API that goes through ThreadRegistration.
Until they are removed, {,Racy}RegisteredThread are given private access to ThreadRegistration{,Data} for easier access.
This means that we can now change uses of RegisteredThread to use ThreadRegistration directly instead, and the data will be the same through either APIs.
Also, RacyRegisteredThread::ThreadId() was unused so it can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D121847
The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
Since ThreadRegistration already handles nested registrations, the legacy profiler_{,un}register_thread() functions don't need to care about that anymore (and the RegisteredThread TLS will be removed in a later patch anyway).
The informational markers have been moved to ProfilerThreadRegistration.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D122315
ProfilerThreadRegistry (un)register functions have been moved to platform.cpp because they need to interact closely with functions and classes in that file.
profiler_{,un}register_thread are now simple calls to ThreadRegistration::{R,Unr}egisterThread, which call ThreadRegistry::{R,Unr}egister, which now integrate that old bodies of profiler_{,un}register_thread.
So from this point, threads may use either profiler_{,un}register_thread or ThreadRegistration equivalents, and this will (un)register with both the new ThreadRegistration classes and the legacy RegisteredThread class into CorePS. (Later patches will remove RegisteredThread completely.)
Bonus: Since the stack top is now adjusted when constructing ThreadRegistrationInfo (before giving it to the legacy ThreadInfo), there is no more need for `GetStackTop()`.
Differential Revision: https://phabricator.services.mozilla.com/D121844
Thread-related APIs that are currently in ProfilerState.h will move here, and will use the new ThreadRegistration classes introduced in bug 1721939.
In this patch the header is empty apart from a few #includes, and users of "ProfilerState.h"'s thread functions now #include "ProfilerThreadState.h" instead. So there are no actual code changes yet.
Differential Revision: https://phabricator.services.mozilla.com/D121843
plugin-syntax-class-properties was supported by default in Babel 7.14.0.
This also adds top level await support in modules with the upgrade to Babel 7.15.0.
Differential Revision: https://phabricator.services.mozilla.com/D122865
The majority of RunningTimes objects would contain zero or near-zero values (no/low activity), so it makes sense to serialize them using ULEB128, which only takes 1 bytes for values under 128, instead of the full 8 bytes.
And high values in the millions would still serialize in 4 bytes or less, half of the 8-byte type size.
This patch is particularly useful now, because `SampleSample` entries are much smaller than `CompactStack` entries, so the size taken by RunningTimes is much more significant now, and saving up to 7 bytes means we could record up to 24% more of these entries in the same buffer space.
Differential Revision: https://phabricator.services.mozilla.com/D122680
Instead of copying the full stack from the previous sample when identical, the new ProfileBufferEntryKind::TimeBeforeSameSample + SameSample entry pair indicates that this is an identical sample. Later when producing the final JSON profile, we can just re-use the same sample identifier as before.
This effectively lowers the size of this kind of entry from hundreds of bytes, down to 20-30 bytes, which should help with capturing more samples in the same buffer size. And it also uses less CPU resources, since we don't need to find the previous stack and copy it.
We still need to perform a full copy at the start of a buffer chunk, to make sure there is always a full stack available in case older previous chunks have been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D122679
We passed 64-bit integer arguments, but `AppendPrintf` took them
as 32-bit parameters. This generated a wrong version string in
32bit build.
Differential Revision: https://phabricator.services.mozilla.com/D122623
`mozilla::profiler::ThreadRegistry` keeps a list of all `ThreadRegistration`s, and makes it safely accessible from any thread.
While a thread is accessing the list, that list cannot be changed (a thread (un)registering itself needs to acquire the associated mutex). In particular, a thread will not disappear during that time, so it's safe to access the `ThreadRegistration` data that is owned by these threads.
The subset of `ThreadRegistrationData` accessor sub-classes available through `ThreadRegistry` is different from direct on-thread access, to guarantee safe access in different circumstances.
For example, `JSContext` may be read through a `LockedRWFromAnyThread`, which requires the per-thread lock, thereby preventing any simultaneous `JSContext` change from the owning thread. And because the `LockedRWOnThread` accessor is not reachable through the registry, it's not allowed, or even possible, to change `JSContext` from other threads.
Differential Revision: https://phabricator.services.mozilla.com/D120818
This class is how a thread will register itself, and contains the thread's relevant data.
A registration-accessor object can be accessed on the thread with `GetOnThreadPtr()` or `WithOnThreadRef{,Or}()`, and from there some of the data accessor may be obtained, with per-thread lock where necessary.
(The next patch will introduce ThreadRegistry to access registrations from other threads.)
Differential Revision: https://phabricator.services.mozilla.com/D120817
Non-virtual sub-classes of `ProfilerThreadRegistrationData` provide layers of public accessors to subsets of the data.
Each level builds on the previous one and adds further access to more data, but always with the appropriate guards where necessary.
These classes have protected constructors, so only some trusted classes (in later patches) will be able to construct them, and then give limited access depending on who asks (the owning thread or another one), and how much data they actually need.
The hierarchy is, from base to most derived:
- `ThreadRegistrationData` (previous patch)
- `ThreadRegistrationUnlockedConstReader`
- `ThreadRegistrationUnlockedConstReaderAndAtomicRW`
- `ThreadRegistrationUnlockedRWForLockedProfiler`
- `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`
- `ThreadRegistrationLockedRWFromAnyThread`
- `ThreadRegistrationLockedRWOnThread`
- `ThreadRegistration::EmbeddedData` (next patch, as data member of `ThreadRegistration`)
Tech detail: These classes need to be a single hierarchy so that the upcoming `ThreadRegistration` class can contain the most-derived class, and from there can publish references to base classes without relying on Undefined Behavior. (It's not allowed to have some object and give a reference to a sub-class, unless that object was *really* constructed as that sub-class at least, even if that sub-class only adds member functions!)
And where appropriate, these references will come along with the required lock.
For example:
JSContext can only be written on the owning thread, through `ThreadRegistrationLockedRWOnThread` (which will be accessed through TLS = Thread Local Storage), which requires a per-thread lock.
Thanks to that, JSContext can be read using `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`, without lock because we're on the owning thread, so there cannot be any write at the same time.
Other threads will be able to read it as well, but they will only see it through `ThreadRegistrationLockedRWFromAnyThread`, which will require the per-thread lock, thereby preventing simultaneous writes.
Differential Revision: https://phabricator.services.mozilla.com/D120816
This class contains the same data as was in `RacyRegisteredThread` and `RegisteredThread`, but this data is kept `protected`, accessors will be added through sub-classes in the next patch, and tests in a later patch once publicly accessible.
Note that `ThreadRegistrationInfo`, `ProfilingStack`, and `PlatformData` are now directly included as values.
The stack top platform-specific code was taken from `GetStackTop()` in platform-win32.cpp and platform-macos.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D120815
This class will contain platform-specific data about threads.
It needs to be public because it will be included as value into the thread registration data (to avoid a separate allocation).
Tests will be added when platform-specific code is implemented in bug 1722261.
Differential Revision: https://phabricator.services.mozilla.com/D120814
`ProfilerThreadRegistrationInfo` will replace `ThreadInfo`, and contains thread-specific information that may be kept after that thread has ended, to identify recorded profiling data about that thread.
It is public and not ref-counted because it will be included as value into the thread registration data (to avoid a separate allocation).
Differential Revision: https://phabricator.services.mozilla.com/D120813
This hides the scProfilerMainThreadId detail, and makes for a safer API.
Also, ::profiler_init_main_thread_id() calls ::mozilla::baseprofiler::profiler_init_main_thread_id().
And in non-MOZ_GECKO_PROFILER builds, AUTO_PROFILER_INIT calls profiler_init_main_thread_id(), which makes other main-thread functions usable there (assuming profiler_current_thread_id works).
Differential Revision: https://phabricator.services.mozilla.com/D121695
This patch only shuffles source code around, so that all declarations in {,Base}ProfilerUtils.h are now implemented only in ProfilerUtils.cpp (instead of the different platform-*.cpp), the final generated code should be the same in MOZ_GECKO_PROFILER builds (the default on all our supported platforms).
This simplifies the headers and makes further changes easier.
In non-MOZ_GECKO_PROFILER builds: On supported platforms these functions are now fully defined; Unsupported platforms should all had `getpid()`, but thread ids are null.
So now `profiler_current_process_id()` is available on all platforms, at all tier levels.
Differential Revision: https://phabricator.services.mozilla.com/D121051
Since ProfilerProcessId and ProfilerThreadId (and their NumberTypes) will potentially grow to 64 bits on some platforms (in a later patch), all code that uses them must be able to handle bigger types.
Differential Revision: https://phabricator.services.mozilla.com/D121049
Mark Banner
Brindusan Cristian
Gerald Squelart
Mike Hommey
André Bargull
Toshihito Kikuchi