The current use of `PodZero` (`memset`) triggers `-Wclass-memaccess`
warnings, and member initializers are arguably nicer.
Differential Revision: https://phabricator.services.mozilla.com/D84690
This patch adds a new measurement to the histogram about the elapsed time
of `ShellExecuteByExplorer`. If ShellExecuteByExplorer takes long in
a considerable number of instances, we need to consider fixing bug 1646986.
Differential Revision: https://phabricator.services.mozilla.com/D84407
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
Having a thread limit of 1 in the background thread pools causes deadlock when attempting synchonous dispatch on the same pool. Increasing the thread limit on each pool to 2 lessens the risk of this kind of deadlock, so it's not the perfect solution where we wouldn't allow any kind of offthread synchronous dispatch that could cause a deadlock. These thread pools may eventually scale larger, so this patch sets the idle thread limit low.
Differential Revision: https://phabricator.services.mozilla.com/D83999
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
This code glues the JS GC code that creates the telemetry with a JS module
that processes it. This patch removes this code unhooking these
components.
Differential Revision: https://phabricator.services.mozilla.com/D84163
This patch introduces a remove method to the IOUtils interface, which allows
for removing files and directories on disk. It is a simple wrapper around
the nsIFile::Remove method.
Differential Revision: https://phabricator.services.mozilla.com/D83663
This also factors out FinalizationRegistry support into a separate class.
The JS engine now passes a callback function and the incumbent global which are recorded in QueueCallback. FinalizationRegistryCleanup::DoCleanup creates a CallbackObject can calls it immediately (I originally tried creating it in QueueCallback but there were problems because this is called during GC).
I coped most of this from the way promise reaction jobs work. I added FinalizationRegistryCleanupCallback; I don't know if that's overkill.
Differential Revision: https://phabricator.services.mozilla.com/D83614
This also factors out FinalizationRegistry support into a separate class.
The JS engine now passes a callback function and the incumbent global which are recorded in QueueCallback. FinalizationRegistryCleanup::DoCleanup creates a CallbackObject can calls it immediately (I originally tried creating it in QueueCallback but there were problems because this is called during GC).
I coped most of this from the way promise reaction jobs work. I added FinalizationRegistryCleanupCallback; I don't know if that's overkill.
Differential Revision: https://phabricator.services.mozilla.com/D83614
CLOSED TREE
Backed out changeset 8b21977bb2df (bug 1648453)
Backed out changeset 4cac71f274b8 (bug 1648453)
Backed out changeset a9ad01b4ab2e (bug 1648453)
This also factors out FinalizationRegistry support into a separate class.
The JS engine now passes a callback function and the incumbent global which are recorded in QueueCallback. FinalizationRegistryCleanup::DoCleanup creates a CallbackObject can calls it immediately (I originally tried creating it in QueueCallback but there were problems because this is called during GC).
I coped most of this from the way promise reaction jobs work. I added FinalizationRegistryCleanupCallback; I don't know if that's overkill.
Differential Revision: https://phabricator.services.mozilla.com/D83614
Dispatching to the underlying thread of what could be a thread-pool can lead to data-race as the code won't be run where you expect it to.
Differential Revision: https://phabricator.services.mozilla.com/D82632
We're crashing occasionally here due to an assertion in Span.h. We would
also likely have problems down the road if we tried to cache nullptrs in
the startup cache. I think this is all we need to handle this as gracefully
as we are able - at least, this should make it so the recent StartupCache
changes are no longer making failure any less graceful.
Differential Revision: https://phabricator.services.mozilla.com/D83189
This runs an extra GC cycle when a worker goes idle if the cycle collector collected anything. This fixes the test case given (but not the case in the original bug).
Differential Revision: https://phabricator.services.mozilla.com/D82869
This builds on the existing static components infrastructure to allow defining
a Services.jsm-type services cache with no runtime memory overhead for any
services until they're accessed.
Any class entry with a 'js_name' attribute automatically becomes available on
the services cache with that name, and any interfaces listed in its
'interfaces' list are automatically queried on it.
Differential Revision: https://phabricator.services.mozilla.com/D81417
This makes it much simpler for the for the static JS services cache to store
and lookup interface IDs for components.
Differential Revision: https://phabricator.services.mozilla.com/D81416
This builds on the existing static components infrastructure to allow defining
a Services.jsm-type services cache with no runtime memory overhead for any
services until they're accessed.
Any class entry with a 'js_name' attribute automatically becomes available on
the services cache with that name, and any interfaces listed in its
'interfaces' list are automatically queried on it.
Differential Revision: https://phabricator.services.mozilla.com/D81417
