This reverts commit ed098a6dfc.
Revert "Bug 2043789: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{io,ioutils}/. r=xpcom-reviewers,emilio"
This reverts commit aa8e617fd8.
Revert "Bug 2043788: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{base,ds}/. r=xpcom-reviewers,emilio"
This reverts commit 4f52fb1147.
This is a regresion from Bug 2010960.
This latent bug was revealed by the next patch in this stack where we are able to
coalesce more microtasks than we were able to before.
The core problem is that coalescing microtasks is supposed to be a transparent
operation, such that -semantically- every microtask is executed in a loop in
its own state setup and torn-down between tasks. However because setup and
teardown are costly, 2010960 hides that cost by draining more microtasks if
they are compatible.
The bug here is that if the AutoHandlingUserInputStatePusher on the first
task, before we try to drain more, indictes we're handling user input, that
leaks into subsequent tasks, since AutoHandlingUserInputStatePusher ahuip(false)
does nothing, rather than clearing the state below it (which was semantically
how I thouht it had worked)
Differential Revision: https://phabricator.services.mozilla.com/D299218
The only wrinkle here is I had to disable warnings about missing designated
field initializers for security/certverifier because it defines -Wextra which
otherwise causes it to complain about this pattern.
Differential Revision: https://phabricator.services.mozilla.com/D299451
MakeAndAddRef ensures that the freshly-allocated object immediately gets a
refcount of 1 (before it's even passed to AddScriptRunner). This avoids
several potential footguns that otherwise exist with a zero-refcount
freshly-allocated object.
It also makes the ownership-transfer semantics more clear
(via the already_AddRefed type that it produces) - AddScriptRunner is taking
ownership of the object, rather than using it temporarily while the caller
maintains ownership.
Differential Revision: https://phabricator.services.mozilla.com/D299039
Stop getting the optionalHostDefinedData object (scheduling state in gecko) for the FinalizationObject
which only needs the incumbent global.
Drive-by: Don't repeat getHostDefined global when it's right there.
Bug 2025988 is about cleaning up some of these naming inconsistencies
Differential Revision: https://phabricator.services.mozilla.com/D284008
The general thrust of this patch stack is that we go from having
[Promise ]
|HostDefinedData Slot | --> JSObject [ 0: InbumbentGlobal,
1: SchedulingState] (almost always exists)
to
[Promise ]
| IncumbentGlobal Slot |
| optionalHostDefinedData Slot | --> JSObject [ 0: SchedulingState ] (almost never exists)
The result of this is improved performance in the common case where the
host never provides anything beyond the incumbent global for the JS engine to carry
about.
Prior to this patch microtasks store incumbent global in one of two ways:
Either as the 'hostDefinedGlobal' or as the incumbent global on the host
defined data object.
After this patch the incumbent global is _always_ stored the same way, and can
be handled the same way; the only thing that is stored in the
'optionalHostDefinedData' is the scheduling state if it exists.
This means incumbent global handling in ExtractIncumbentAndSchedulingState is
nicely simplified.
This is a rollup of D277008, D277009, D277010, D277011, D282284, D284008.
Differential Revision: https://phabricator.services.mozilla.com/D297138
Currently this checks whether it needs to dispatch a runnable based on whether
there are already callbacks in mCallbacks, but it can just as easily keep a
weak pointer to any dispatched runnable and that lets us signal to the runnable
that there's nothting to do when FinalizationRegistryCleanup is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D289786
Currently this checks whether it needs to dispatch a runnable based on whether
there are already callbacks in mCallbacks, but it can just as easily keep a
weak pointer to any dispatched runnable and that lets us signal to the runnable
that there's nothting to do when FinalizationRegistryCleanup is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D289786
Currently this checks whether it needs to dispatch a runnable based on whether
there are already callbacks in mCallbacks, but it can just as easily keep a
weak pointer to any dispatched runnable and that lets us signal to the runnable
that there's nothting to do when FinalizationRegistryCleanup is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D289786
To be able to use the same interface for inspecting microtasks which get peeked,
we break apart the class into a small hierarchy to make it clear what consumes which when.
Differential Revision: https://phabricator.services.mozilla.com/D282843
There's a small functionality change here: a task which is discarded and never run will not have a
~zero duration marker in the profiler, unlike previously
(also moved comment where more relevant)
Differential Revision: https://phabricator.services.mozilla.com/D282841
Once we have broken apart CallSetup we can actually just use scoped allocation and deallocation.
This patch also takes the opportunity to stop doing a TLS get for CycleCollectedJSContext given
we always already have that pointer just up the callstack.
Differential Revision: https://phabricator.services.mozilla.com/D282833
This is an extremely simple hand-inlining of CallSetup. This is done to reveal
specialization and reorganization opportunities that are hidden behind the
CallSetup interface.
Differential Revision: https://phabricator.services.mozilla.com/D282831
To be able to use the same interface for inspecting microtasks which get peeked,
we break apart the class into a small hierarchy to make it clear what consumes which when.
Differential Revision: https://phabricator.services.mozilla.com/D282843
There's a small functionality change here: a task which is discarded and never run will not have a
~zero duration marker in the profiler, unlike previously
(also moved comment where more relevant)
Differential Revision: https://phabricator.services.mozilla.com/D282841
Once we have broken apart CallSetup we can actually just use scoped allocation and deallocation.
This patch also takes the opportunity to stop doing a TLS get for CycleCollectedJSContext given
we always already have that pointer just up the callstack.
Differential Revision: https://phabricator.services.mozilla.com/D282833
This is an extremely simple hand-inlining of CallSetup. This is done to reveal
specialization and reorganization opportunities that are hidden behind the
CallSetup interface.
Differential Revision: https://phabricator.services.mozilla.com/D282831
Daniel Holbert