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
We are using the OS version as reported in the user agent string, but on macOS the version is capped at 10.15. This patch now reports the real and full OS version.
Differential Revision: https://phabricator.services.mozilla.com/D122063
This makes all our stackwalkers in Firefox consistent with respect to return addresses:
For non-leaf frames in stacks, the code address now always points to the instruction
*after* the call instruction, i.e. to the instruction that will be executed once the
function returns.
For symbolication purposes, 1 byte will need to be subtracted in order to obtain correct
line number + inline stack information for the call instruction. This subtraction will
be the responsibility of the Firefox profiler front-end, not of the stackwalkers.
Depends on D121930
Differential Revision: https://phabricator.services.mozilla.com/D121931
This will make it so that, for return addresses, symbolication can look up
the address "returnAddress - 1" and get the correct line number (and inline
stack) for the call instruction.
Without the masking, returnAddress - 1 might still fall into the instruction
*after* the call instruction, giving wrong line numbers / inline stacks.
Differential Revision: https://phabricator.services.mozilla.com/D121930
When mfplat.dll loads msvp9dec_store.dll, it posts a task
to unload the module to the work queue even if msvp9dec_store.dll
is already loaded and mfplat.dll skips LoadLibrary. Therefore,
we cannot safely lock msvp9dec_store.dll by loading it as data.
The proposed fix is to skip processing the module.
Differential Revision: https://phabricator.services.mozilla.com/D121777
This is a prerequisite for adding a marker API. There is the same API for C++
as `profiler_can_accept_markers`. This API can both be used as an external API
before adding an expensive payload to the profile marker, and it can be used as
an internal function to check it inside the new `add_marker` API that will be
introduced soon.
Differential Revision: https://phabricator.services.mozilla.com/D121535
This is a syntactic sugar for `gecko_profiler_label` API. When you use this
macro on top of a function, it will automatically expand the function content
with `gecko_profiler_label` macro call.
Differential Revision: https://phabricator.services.mozilla.com/D120794
Bindgen will be needed for gecko_profiler::is_active gecko_profiler_label API
in this patch, as well as the marker API that will land after this.
Differential Revision: https://phabricator.services.mozilla.com/D120789
Mark Banner
Gerald Squelart
Mike Hommey
André Bargull
Toshihito Kikuchi
Kimberly Sereduck
Alex Lopez
Butkovits Atila
Markus Stange
Florian Quèze
Nazım Can Altınova
Emilio Cobos Álvarez
Barret Rennie
Zibi Braniecki
Andrew Osmond
Noemi Erli