Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
Various tests disable process preallocation in order to get "stable" process
counts for testing purposes. In order to keep this behaviour, we need to disable
and shut down the recycled E10S process whenever the preallocator is disabled.
This is accomplished by having the preallocator expose its enabled status to
ContentParent, and by having the preallocator trigger ContentParent shutdown
when it is disabled.
This also has the benefit of hooking the recycler back into memory pressure
notifications, meaning it will be shut down if not in use when a memory pressure
event occurs.
Differential Revision: https://phabricator.services.mozilla.com/D88628
Previously, we would use the PreallocatedProcessManager to handle recycled
"web" content processes, which would remove them from the pool and try to make
them act like "prealloc" content processes.
Unlike true preallocated content processes, we can end up having content loaded
in recycled "web" content processes, such as due to a new pop-up being created
at an inconvenient time during process teardown. The complexity around this
semi-prealloc state caused some assertion failures in other related code.
This new approach doesn't remove the recycled process from the process selection
pool. Instead, after process selection decides to spawn a new "web" process, a
pointer to the specific "recycled" content process is fetched and returned by
the process selection algorithm before asking the preallocator.
This new approach should have similar behaviour, but avoids some of the pitfalls
caused by removing the entry from the process selection pool after it has begun
hosting content.
Differential Revision: https://phabricator.services.mozilla.com/D88625
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354