Remove mWorkerPrivate from WorkerMainThreadRunnable. Instead, using a ThreadSafeWorkerRef to keep Worker alive until the created syncLoop is destroyed.
In general, WorkerMainThreadRunnable::mWorkerPrivate is only used for dispatching the MainThreadStopSyncLoopRunnable back to the Worker thread. Because of the syncLoop, the Worker is supposed to be kept alive until the created syncLoop is destroyed.
RefPtr<ThreadSafeWorkerRef> WorkerMainThreadRunnable::mWorkerRef is introduced to ensure a valid WorkerPrivate during WorkerMainThreadRunnable's execution.
WorkerMainThreadRunnable::mWorkerRef is allocated just before creating a syncLoop in WorkerMainThreadRunnable::Dispatch. And released after the created syncLoop::Run() finishes.
Depends on D212556
Differential Revision: https://phabricator.services.mozilla.com/D212557
Once WorkerPrivate::ResetWorkerPrivateInWorkerThread() is called, the connection between the WorkerPrivate and the WorkerThread is decoupled. This means the WorkerPrivate is not valid anymore for any WorkerThreadRunnables. So, before decoupling the WorkerPrivate and WorkerThread, we should ensure all pending WorkerThreadRunnables are executed, and the Worker should be in the "Dead" status.
It means the logic in the WorkerPrivate::RunLoopNeverRan() except WorkerPrivate::ScheduleDeletion() should be executed before WorkerPrivate::ResetWorkerPrivateInWorkerThread(). However, currently, these logic are executed after ResetWorkerPrivateInWorkerThread().
Differential Revision: https://phabricator.services.mozilla.com/D210775
There was existing code to read the prefs, but the prefs themselves had been removed.
I renamed the prefs in line with all the other JS GC options, so starting
javascript.options.mem.gc_.
Differential Revision: https://phabricator.services.mozilla.com/D210059
Sensible defaults are very different for the browser and the shell so I added
separate constants. I think the JS testing functions can get called from the
browser and so may pick the wrong default but it's not too serious.
Differential Revision: https://phabricator.services.mozilla.com/D210058
Atomics.wait prevent WorkerDebuggerRunnable's from running by blocking the event loop.
While dispatching these runnables, also spawn a short timer which would interrupt the worker
and tentatively try to drain the debugger queue and resume any debugger runnable which may be blocked.
Differential Revision: https://phabricator.services.mozilla.com/D194081
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
In this patch, WorkerParentThreadRunnable is extracted from WorkerThreadRunnable for runnable on the parent thread.
WorkerParentControlRunnable and WorkerParentDebuggeeRunnable are also created for control runnable and debuggee runnable on the parent thread.
Instead of using WorkerRunnable::Target to indicate the thread target, inheriting WorkerThreadRunnable or WorkerParentThreadRunnable to point out that this runnable should run on the worker thread or on the parent thread. So WorkerRunnable::Target is removed in this patch.
This patch also move the dispatching logic into WorkerPrivate to simplify WorkerRunnable::DispatchInternal()'s implementation.
Depends on D205178
Differential Revision: https://phabricator.services.mozilla.com/D205679
This is the first step in splitting the parent thread runnable out of WorkerRunnable.
To reuse the runnable dispatching codes in Worker, we still need a base class for runnable on the worker thread and the parent thread.
In this patch, we rename the original WorkerRunnable to WorkerThreadRunnable and make WorkerRunnable to be WorkerThreadRunnable's parent class.
In the second patch, we will create WorkerParentThreadRunnable and its sub-classes, split from WorkerThreadRunnable for runnable on the Worker's parent thread.
And in the third patch, we will re-structure the content of WorkerParentThreadRunnable to remove unnecessary members.
Differential Revision: https://phabricator.services.mozilla.com/D205178
Add a GC parameter and pref for semispace nursery which is disabled by default.
Enable it for the shell rootanalysis job to get get some test coverage.
Differential Revision: https://phabricator.services.mozilla.com/D196431
mLocale is currently initialized in IndexedDatabaseManager::Init which is
called from IndexedDatabaseManager::GetOrCreate if the manager doesn't exist.
This can be a problem when IndexedDatabaseManager::GetOrCreate is called very
early,for example in nsLayoutStatics::Initialize in the parent process.
This is a preparation for moving IndexedDatabaseManager::GetOrCreate from
FactoryOp::Open to InitializeQuotaManager.
Differential Revision: https://phabricator.services.mozilla.com/D189891
This adds a per-process count of helper threads 'reserved' for parallel
marking. This means reserved with respect to parallel marking but not anything
else, so helper threads can still be used for other tasks (including GC
parallel tasks) but the number of runtimes that can mark in parallel is
limited.
The main runtime reserves threads when parallel marking is enabled to
priviledge it over worker runtimes. Workers reserve threads only for the
duration of collection. Failure to reserve threads means parallel marking is
not used.
I don't love the term 'reserved' beacuse it implies the threads cannot be used
for anything else, but I couldn't think of anything better. I've added comments
to describe what it actually means.
Differential Revision: https://phabricator.services.mozilla.com/D201695
Atomics.wait prevent WorkerDebuggerRunnable's from running by blocking the event loop.
While dispatching these runnables, also spawn a short timer which would interrupt the worker
and tentatively try to drain the debugger queue and resume any debugger runnable which may be blocked.
Differential Revision: https://phabricator.services.mozilla.com/D194081
This patch is only remove the inheriting, but keeping Cancel() implmentation.
The Cancel() is needed in some special cases, such as Worker enters Canceling when WorkerScope is not created.
Depends on D176915
Differential Revision: https://phabricator.services.mozilla.com/D173850
And relax the check if someone carries away a stale reference to our global scope to happen after the JS context has gone out of scope.
Differential Revision: https://phabricator.services.mozilla.com/D150942
When running an infinitely-looping dynamic import, it is possible for the module loader to still be
holding on to that module at shutdown. Shutdown on the worker means that we will no longer run the
event loop, which will execute the dynamic import promises necessary to clear the global. The result
is that the global is kept alive. By calling `Shutdown()` we prevent this partially. We additionally
need to address the failure in the module code (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D171683
