`NoPayload` will be mostly used internally when adding markers without payload data.
It has an empty specialization of the MarkerTypeHelper (mainly to catch misuses), and the add-marker code will need to have different compile-time paths to handle it.
Differential Revision: https://phabricator.services.mozilla.com/D87252
`profiler_capture_backtrace(ProfileChunkedBuffer&)` renamed to `profiler_capture_backtrace_into(ProfileChunkedBuffer&)` (notice "_into"), which is clearer.
New function `profiler_capture_backtrace()` creates a buffer, uses `profiler_capture_backtrace_into()`, and returns a `UniquePtr<ProfileChunkedBuffer>`, which can later be given to `MarkerStack::TakeBacktrace`.
`profiler_get_backtrace()` (returning a `UniqueProfilerBacktrace`) now uses `profiler_capture_backtrace()`.
This patch reduces most duplicate code between these functions.
Differential Revision: https://phabricator.services.mozilla.com/D88280
This moves the existing MarkerTiming class introduced in bug 1640969 to the BaseProfilerMarkersPrerequesites.h header, and can be used as a marker option.
Some minor clarifying changes:
- `Instant()` is split into two functions: `InstantNow()` and `InstantAt(TimeStamp)`.
- `Interval(TimeStamp, TimeStamp)` must be given both start and end, otherwise `IntervalUntilNowFrom(TimeStamp)` takes the start only and ends "now".
Also the default construction is now reserved for internal marker usage, the private member function `IsUnspecified()` will be used by the add-marker code will replace it with `InstantNow()`.
The serialization contains the phase, and only one or two timestamps as needed, to save space for non-interval timings.
Differential Revision: https://phabricator.services.mozilla.com/D87245
The upcoming profiler-specific add-marker function will need to know which `ProfileChunkedBuffer` to serialize to, `profiler_get_core_buffer()` give access to the profiler's buffer, and `CachedCoreBuffer()` keeps it stored in a function-static object.
Differential Revision: https://phabricator.services.mozilla.com/D87256
These string views are similar to `std::string_view`, but they are optimized to be serialized in the profiler buffer, and later deserialized and streamed to JSON.
They accept literal strings, and keep them as unowned raw pointers and sizes.
They also accept any substring reference, assuming that they will only be used as parameters during function calls, and therefore the dependent string will live during that call where these `StringView`'s are used.
Internally, they also allow optional string ownership, which is only used during deserialization and streaming.
This is hidden, so that users are not tempted to use potentially expensive string allocations during profiling; it's only used *after* profiling, so it's less of an impact to allocate strings then. (But it could still be optimized later on, as part of bug 1577656.)
Differential Revision: https://phabricator.services.mozilla.com/D87242
This patch introduces all new files that contain the new markers C++ API and implementation.
They are mostly empty at this time, only including each other as eventually needed, and with `#ifdef MOZ_GECKO_PROFILER` guards.
Rough inclusion diagram: (header <-- includer)
BaseProfilerMarkerPrerequesites.h <-- ProfilerMarkerPrerequesites.h (Useful types: Input string view, marker options)
^ ^
BaseProfilerMarkerDetail.h <-- ProfilerMarkerDetail.h (Implementation details)
^ ^
BaseProfilerMarkers.h <-- ProfilerMarkers.h (Main API)
^ ^--------- ^ ^---------
BaseProfilerMarkerTypes.h | <-- ProfilerMarkerTypes.h | (Common marker types)
^ BaseProfiler.h <-- GeckoProfiler.h (Existing main profiler headers)
Differential Revision: https://phabricator.services.mozilla.com/D87241
This test begins to fail due to a `pip` installation issue after bug 1660351. It's already disabled on macOS (also due to what the comment says is a `pip` installation issue), so it's very possible the custom `requirements.txt` that this test installs is deficient in some way that surfaces in certain `virtualenv`s under certain circumstances. I can't diagnose the failure, but what I have seen is that bug 1659539 will fix that problem entirely with no extra intervention required, so we should be able to re-enable this for Linux (and maybe macOS as well?) when that patch lands.
Differential Revision: https://phabricator.services.mozilla.com/D88653
This change makes eslint aware of the global IOUtils interface, such that it
may be used without having to access it from the window or otherwise declaring
the global in a special comment on a file-by-file basis.
Differential Revision: https://phabricator.services.mozilla.com/D87612
In most calls to `SpliceableJSONWriter::Splice(const char*)`:
- The data comes from a `ChunkedJSONWriteFunc` and is copied to a new buffer, which is then copied again through `Write()`. Instead we can copy the data directly from the `ChunkedJSONWriteFunc`; and this is a nice complement to `TakeAndSplice()` below.
- Or the length is already known, so we can pass it to a new `Splice(const char*, size_t)`, which forwards it to `Write(const char*, size_t)`, saving one `strlen` call.
Differential Revision: https://phabricator.services.mozilla.com/D87703
`SpliceableChunkedJSONWriter::ChunkedWriteFunc` returns a `ChunkedJSONWriteFunc*`, which is never null and is either used to:
1. Copy data.
2. Or take ownership of the chunks.
In the first case, `ChunkedWriteFunc()` now returns a `const ChunkedJSONWriteFunc&` (notice "const &"), so only const members may be used to copy the data.
In the second case, a new function `TakeChunkedWriteFunc()` returns `ChunkedJSONWriteFunc&&` (notice "&&"), so it's clear that its chunks can be taken away. Some `DEBUG` assertions help ensure that it's not used anymore after that.
`TakeAndSplice()` now takes a `ChunkedJSONWriteFunc&&`.
All callers have been updated to the more appropriate functions.
Differential Revision: https://phabricator.services.mozilla.com/D87702
This change makes eslint aware of the global IOUtils interface, such that it
may be used without having to access it from the window or otherwise declaring
the global in a special comment on a file-by-file basis.
Differential Revision: https://phabricator.services.mozilla.com/D87612
Currently the `jest/no-standalone-expect` rule needs to be disabled for `jest-in-case` cases blocks as it is not compatible.
Differential Revision: https://phabricator.services.mozilla.com/D87184
To ensure correct usage of TLSs in the profiler, they are now better encapsulated so that:
- init() is called once and its result is cached. (TLSREGISTEREDThread::Init() doesn't need proof of the PSLock, because it's using thread-safe function-static initializers.)
- get() and set() always init() as needed, or in some particular cases strongly assert that init() was successful.
Also, a null-check was missing in profiler_init_threadmanager().
Depends on D87588
Differential Revision: https://phabricator.services.mozilla.com/D87589
Assertions are also clarified with messages, to better distinguish the same tests in different locations.
Assertions should now cover all cases:
- NEW: After registering a thread in the profiler with `CorePS::AppendRegisteredThread`, the TLS should be set to that thread.
- NEW: If `profiler_register_thread` is called again, the TLS should still be set to that thread.
- When `profiler_unregister_thread` is first called, the TLS should still be set to that thread (that's the assertion currently trigering this bug 1657174),
- NEW: When `profiler_unregister_thread` is first called and after we remove the thread with `CorePS::RemoveRegisteredThread`, the TLS should now be null.
- If `profiler_unregister_thread` is called again (or with a never-registered thread), the TLS should be null.
This is a further exploratory patch for bug 1657174, this will not prevent crashes, but hopefully it should give a bit more information, at least a smaller range in which the possible presumed registration/TLS race happens.
Differential Revision: https://phabricator.services.mozilla.com/D87588
There are zero uses of this `mach` command over the past 90 days according to our telemetry. There are no external references to `mach python-safety` in-tree, and indeed if you track the history of the originating bug 1468394, it appears that once the `mach` command was created, none of the follow-up work that was discussed (i.e. running this in CI and triaging failures to appropriate owners) was done over the following 2 years.
If this ever does appear to be useful in the future, we can just resurrect this code from source control.
Differential Revision: https://phabricator.services.mozilla.com/D87351
Before this patch, we were always waiting for libxul to load because we were
starting the JVM from libxul. But we needed to start this a lot earlier. Also
thinking that JVM profiler can actually run without the gecko side, we can
start this a lot earlier than we currently start. We need to check the
environmnet variables to be able to start the profiler. It looks like the best
place to do it is inside the GeckoThread.run method.
We have also a similar code for Java debugger, with maybeWaitForJavaDebugger
name. This fucntion does similar things in terms of enviromnent variable
handling.
Differential Revision: https://phabricator.services.mozilla.com/D87069
