searching for reviewer(sfink)
71ad06caf9b67fde7e73042e748fc3cc5a34c4a1: Bug 1716940 - Pass external thread stack size through to the JS engine r=sfink,bas
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 17 Jun 2021 16:14:19 +0000 - rev 583720
Push 38550 by mlaza@mozilla.com at Fri, 18 Jun 2021 09:20:56 +0000
Bug 1716940 - Pass external thread stack size through to the JS engine r=sfink,bas This adds plumbing to make the JS engine set the stack quota based on the actual stack size for external thread pool threads (and internal thread pool ones). The quota is calculated as 90% of the size, which is currently hardcoded into the constants. Differential Revision: https://phabricator.services.mozilla.com/D118183
36647ef6f014ee7199a0bad93851750ead132473: Bug 1716250 - Remove JS_FRIEND_API. r=jandem,sfink
Ted Campbell <tcampbell@mozilla.com> - Wed, 16 Jun 2021 19:38:10 +0000 - rev 583580
Push 38543 by apavel@mozilla.com at Wed, 16 Jun 2021 21:42:00 +0000
Bug 1716250 - Remove JS_FRIEND_API. r=jandem,sfink Convert all JS_FRIEND_API to JS_PUBLIC_API. At this point, the JS_PUBLIC_API has no formal curation process and in practice we add a lot of new features to JS_FRIEND_API without giving much thought to if they should be public. The result is that all embedders need to use the friend API in some form and the distinction has lost meaning. Going forward, we should continue to use the js/public/experimental directory as a place to expose new APIs, and in general should strive for high quality of the APIs that are exposed. If a particular API is tricky or discouraged, comments explaining that will be more helpful that a losely applied FRIEND_API marker. Differential Revision: https://phabricator.services.mozilla.com/D117607
cbb81a00983e4825a5d10110b440949a83659455: Bug 1711415 - Ensure we always step the budget by some amount when executing parallel GC work r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 16 Jun 2021 14:16:49 +0000 - rev 583538
Push 38543 by apavel@mozilla.com at Wed, 16 Jun 2021 21:42:00 +0000
Bug 1711415 - Ensure we always step the budget by some amount when executing parallel GC work r=sfink SliceBugdet::step asserts that its argument is non-zero. Usually this is a constant that is directly passed in, but in ParallelWorker it comes from a function that returns some estimate of the work done. The problem is that in this case we sweep an empty hash map the estimated work returned is zero. The fix is just to ensure that we pass at least one as the steps. Differential Revision: https://phabricator.services.mozilla.com/D118007
dba01ea36c18a636ccdf5d58644de41003ef38ff: Bug 1715562 - Turn on use of external thread pool for JS helper tasks r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 16 Jun 2021 08:13:40 +0000 - rev 583507
Push 38543 by apavel@mozilla.com at Wed, 16 Jun 2021 21:42:00 +0000
Bug 1715562 - Turn on use of external thread pool for JS helper tasks r=sfink Differential Revision: https://phabricator.services.mozilla.com/D117521
58137e59d8fc3e6404c7c72520c8a0adbc6de92a: Bug 1716247 - Add js::RootedUntypedBase type. r=sfink
Ted Campbell <tcampbell@mozilla.com> - Tue, 15 Jun 2021 17:34:33 +0000 - rev 583280
Push 38541 by csabou@mozilla.com at Wed, 16 Jun 2021 03:36:43 +0000
Bug 1716247 - Add js::RootedUntypedBase type. r=sfink Add a common base type with the template parameter erased. This lets us remove the RootListEntry type and the undefined reinterpret_casts it is using. Depends on D117604 Differential Revision: https://phabricator.services.mozilla.com/D117605
0ea7f627a71737d8ee9a3b42f249cf94fa731f36: Bug 1716247 - Add js::PersistentRootedBase type. r=sfink
Ted Campbell <tcampbell@mozilla.com> - Tue, 15 Jun 2021 17:34:33 +0000 - rev 583279
Push 38541 by csabou@mozilla.com at Wed, 16 Jun 2021 03:36:43 +0000
Bug 1716247 - Add js::PersistentRootedBase type. r=sfink Add a common base type for all PersistentRooted instead of relying on undefined reinterpret_casts. This avoids PersistentRooted<RootListEntry*> which causes potential issues when SpiderMonkey is used in a project compiled under MSVC. The static_cast is still unchecked so the same care needs to be taken as before. Depends on D117603 Differential Revision: https://phabricator.services.mozilla.com/D117604
c52f0e7918ecfd9611cea016c16a2ee88a427709: Bug 1716247 - Remove dead code from GC rooting API. r=sfink
Ted Campbell <tcampbell@mozilla.com> - Tue, 15 Jun 2021 17:34:32 +0000 - rev 583278
Push 38541 by csabou@mozilla.com at Wed, 16 Jun 2021 03:36:43 +0000
Bug 1716247 - Remove dead code from GC rooting API. r=sfink Differential Revision: https://phabricator.services.mozilla.com/D117603
7c328e2c7d273b4c40e428fdfae11b6b599c8aac: Bug 1714141 - Remove unused 'producer' condition variable r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 14 Jun 2021 12:24:47 +0000 - rev 582963
Push 38538 by ncsoregi@mozilla.com at Mon, 14 Jun 2021 21:54:08 +0000
Bug 1714141 - Remove unused 'producer' condition variable r=sfink This is unused since the internal thread pool has its own now. Differential Revision: https://phabricator.services.mozilla.com/D117162
9993292e9eccd9d698b5c29930b117ee74a42923: Bug 1714141 - Use dispatch callback for internal thread pool r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 14 Jun 2021 12:24:47 +0000 - rev 582962
Push 38538 by ncsoregi@mozilla.com at Mon, 14 Jun 2021 21:54:08 +0000
Bug 1714141 - Use dispatch callback for internal thread pool r=sfink We can use the dispatch task callback for the internal thread pool too, removing some code specific to the latter. Differential Revision: https://phabricator.services.mozilla.com/D117161
921f7b14b7c51c43a57e4e92e8dcabe3d357a86f: Bug 1714141 - Move internal thread pool into a new class r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 14 Jun 2021 12:24:46 +0000 - rev 582961
Push 38538 by ncsoregi@mozilla.com at Mon, 14 Jun 2021 21:54:08 +0000
Bug 1714141 - Move internal thread pool into a new class r=sfink Mostly this moves the code over to a new InternalThreadPool class in a new source file. The initialization and shutdown code had to change a little to make this work. Differential Revision: https://phabricator.services.mozilla.com/D117160
b0ec74e735f88b83e26da198bfacbf757b9ba41c: Bug 1714141 - Make helper thread accessors private and remove only external use r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 14 Jun 2021 12:24:46 +0000 - rev 582960
Push 38538 by ncsoregi@mozilla.com at Mon, 14 Jun 2021 21:54:08 +0000
Bug 1714141 - Make helper thread accessors private and remove only external use r=sfink These are going to be removed. Differential Revision: https://phabricator.services.mozilla.com/D117159
cd87dcdae2f3d70eb3c62440dc087511df51cab6: Bug 1682632 - ExtensionEventManager should use a JS::Rooted<JSObject*> as key in the mListeners JS::GCHashMap. r=sfink,baku
Luca Greco <lgreco@mozilla.com> - Fri, 11 Jun 2021 18:58:12 +0000 - rev 582875
Push 38533 by nerli@mozilla.com at Sat, 12 Jun 2021 09:41:20 +0000
Bug 1682632 - ExtensionEventManager should use a JS::Rooted<JSObject*> as key in the mListeners JS::GCHashMap. r=sfink,baku This change is meant to handle the `mach hazards` failure that triggered a backout of this stack of patches, ExtensionEventManager::AddListener/RemoveListener should use a JS::Rooted object as a key in the GCHashMap. The GCHashMap has been added into ExtensionEventManager as part of D80610 ("part2.2: ExtensionEventListener xpcom interface base implementation"), this patch adds the necessary changes on top of that patch. (I've also double-checked locally that these changes should not be triggering the `mach hazards` failure anymore and confirmed that all the unit tests part of this stack of patches are completing successfully). Differential Revision: https://phabricator.services.mozilla.com/D117538
a502d01a397533f15f0ecb9d9ce9ce1b725bb39d: Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Fri, 11 Jun 2021 18:58:10 +0000 - rev 582871
Push 38533 by nerli@mozilla.com at Sat, 12 Jun 2021 09:41:20 +0000
Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink Depends on D84686 Differential Revision: https://phabricator.services.mozilla.com/D84687
40821b435c187314245c93b5f81ae080b5d644d4: Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Fri, 11 Jun 2021 18:58:08 +0000 - rev 582867
Push 38533 by nerli@mozilla.com at Sat, 12 Jun 2021 09:41:20 +0000
Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink Depends on D80609 Differential Revision: https://phabricator.services.mozilla.com/D80610
b4a5d27478615d03f88e67e7870176b40428e9ef: Bug 1714141 - Remove unused 'producer' condition variable r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 11 Jun 2021 10:34:43 +0000 - rev 582799
Push 38532 by abutkovits@mozilla.com at Fri, 11 Jun 2021 21:39:35 +0000
Bug 1714141 - Remove unused 'producer' condition variable r=sfink This is unused since the internal thread pool has its own now. Differential Revision: https://phabricator.services.mozilla.com/D117162
ab5b2926963ad31fd24f736e1512609a2776d859: Bug 1714141 - Use dispatch callback for internal thread pool r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 11 Jun 2021 10:34:43 +0000 - rev 582798
Push 38532 by abutkovits@mozilla.com at Fri, 11 Jun 2021 21:39:35 +0000
Bug 1714141 - Use dispatch callback for internal thread pool r=sfink We can use the dispatch task callback for the internal thread pool too, removing some code specific to the latter. Differential Revision: https://phabricator.services.mozilla.com/D117161
49dcb1536d0ac0b13598eaa3e7de6cdca30ba8e2: Bug 1714141 - Move internal thread pool into a new class r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 11 Jun 2021 10:34:43 +0000 - rev 582797
Push 38532 by abutkovits@mozilla.com at Fri, 11 Jun 2021 21:39:35 +0000
Bug 1714141 - Move internal thread pool into a new class r=sfink Mostly this moves the code over to a new InternalThreadPool class in a new source file. The initialization and shutdown code had to change a little to make this work. Differential Revision: https://phabricator.services.mozilla.com/D117160
a2e92a213ed21f396939868a195fd8db1ff1dd8a: Bug 1714141 - Make helper thread accessors private and remove only external use r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 11 Jun 2021 10:34:42 +0000 - rev 582796
Push 38532 by abutkovits@mozilla.com at Fri, 11 Jun 2021 21:39:35 +0000
Bug 1714141 - Make helper thread accessors private and remove only external use r=sfink These are going to be removed. Differential Revision: https://phabricator.services.mozilla.com/D117159
1d9496c8460ae0a46da1f0afe1bb7ea7c9462b28: Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:19 +0000 - rev 582706
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink This also renames the waitForAllThreads method to the more accurate waitForAllTasks. Differential Revision: https://phabricator.services.mozilla.com/D117005
63c15ae1b2fd506b1b2a43f265aaf7a9dea8f1d4: Bug 1713335 - Shutdown helper thread system with lock held r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:19 +0000 - rev 582705
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Shutdown helper thread system with lock held r=sfink This allows any external tasks that happen to run after the helper thread system has shut down to correctly detect that. This shouldn't happen with the next patch but it seems safer to do it this way. Differential Revision: https://phabricator.services.mozilla.com/D117004
b9ddcd04f43da1dfd92297dab8123a9b140ce4c8: Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:18 +0000 - rev 582704
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink Tasks are dispatched by queueing a generic task for the pool. When this is executed it will run the highest priority task pending, if any. In a busy system it's possible that there will be some delay between dispatching this task and it starting running. There is also a limit on the number of tasks that are run at once for each task kind. The patch therefore limits the number of tasks dispatched to the number of avilable threads. Differential Revision: https://phabricator.services.mozilla.com/D116817
91b32f60431279089bd9a7d5ba3dccd2c9f7364c: Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:18 +0000 - rev 582703
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink Differential Revision: https://phabricator.services.mozilla.com/D116816
0fe894ecc8a96a34df93df055d0fee9ad0961829: Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:18 +0000 - rev 582702
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink I missed this when moving findHighestPriorityTask out of HelperThread previously. Differential Revision: https://phabricator.services.mozilla.com/D116815
a10d0b84ea404cd309a7604eb0dc4499329410c7: Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:17 +0000 - rev 582701
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink This is a stronger condition because we assert CanUseExtraThreads during initialization. It's also closer to to the original intent. Differential Revision: https://phabricator.services.mozilla.com/D116814
adc6a4a58aada32ee4126784ed6cd43f9031be1f: Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 10 Jun 2021 15:14:17 +0000 - rev 582700
Push 38531 by mlaza@mozilla.com at Fri, 11 Jun 2021 09:42:05 +0000
Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink The previous patch added a pref to control use of the external thread pool. I don't think we need an environment variable as well, although I could be persuaded to keep this. Differential Revision: https://phabricator.services.mozilla.com/D116813
8b8bd2385503a2b2fd9f91bc25fc4a007bf924be: Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Thu, 10 Jun 2021 09:34:55 +0000 - rev 582636
Push 38530 by imoraru@mozilla.com at Thu, 10 Jun 2021 21:50:38 +0000
Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink Depends on D84686 Differential Revision: https://phabricator.services.mozilla.com/D84687
a647c0cb85e4194ec8284876f55e5b3f1c27cad1: Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Thu, 10 Jun 2021 09:34:54 +0000 - rev 582632
Push 38530 by imoraru@mozilla.com at Thu, 10 Jun 2021 21:50:38 +0000
Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink Depends on D80609 Differential Revision: https://phabricator.services.mozilla.com/D80610
9e321d3b964bd7194108fb8033dfd28cf76e42ed: Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Wed, 09 Jun 2021 19:20:44 +0000 - rev 582532
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1682632 - part2.6: ExtensionEventListener callListener sendResponse callback parameter. r=baku,sfink Depends on D84686 Differential Revision: https://phabricator.services.mozilla.com/D84687
1bc53013f8b30140204a596f330ece7c154ec208: Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink
Luca Greco <lgreco@mozilla.com> - Wed, 09 Jun 2021 19:20:42 +0000 - rev 582528
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1682632 - part2.2: ExtensionEventListener xpcom interface base implementation. r=baku,sfink Depends on D80609 Differential Revision: https://phabricator.services.mozilla.com/D80610
85042c2c36baf3730785ab305cef85d41d8abc58: Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:55 +0000 - rev 582463
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink This also renames the waitForAllThreads method to the more accurate waitForAllTasks. Differential Revision: https://phabricator.services.mozilla.com/D117005
a460cd7e818da1071545c4ba5a9b4904902edf15: Bug 1713335 - Shutdown helper thread system with lock held r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:55 +0000 - rev 582462
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Shutdown helper thread system with lock held r=sfink This allows any external tasks that happen to run after the helper thread system has shut down to correctly detect that. This shouldn't happen with the next patch but it seems safer to do it this way. Differential Revision: https://phabricator.services.mozilla.com/D117004
21a7a9dbf79daa93dd1172f5b3a9277cfadcb2f4: Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:55 +0000 - rev 582461
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink Tasks are dispatched by queueing a generic task for the pool. When this is executed it will run the highest priority task pending, if any. In a busy system it's possible that there will be some delay between dispatching this task and it starting running. There is also a limit on the number of tasks that are run at once for each task kind. The patch therefore limits the number of tasks dispatched to the number of avilable threads. Differential Revision: https://phabricator.services.mozilla.com/D116817
9c68d8591ef30aa45da5f17862a135d1b4a111ae: Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:54 +0000 - rev 582460
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink Differential Revision: https://phabricator.services.mozilla.com/D116816
18e3f8bf64045527cc1a5764b2e5d2fbc8a38123: Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:54 +0000 - rev 582459
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink I missed this when moving findHighestPriorityTask out of HelperThread previously. Differential Revision: https://phabricator.services.mozilla.com/D116815
5a395f40ac522717bf3cda7ace72c579394b5416: Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:53 +0000 - rev 582458
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink This is a stronger condition because we assert CanUseExtraThreads during initialization. It's also closer to to the original intent. Differential Revision: https://phabricator.services.mozilla.com/D116814
b9b2e74e753067b8b0c1c8c889491d85c5b6c520: Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 14:19:53 +0000 - rev 582457
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink The previous patch added a pref to control use of the external thread pool. I don't think we need an environment variable as well, although I could be persuaded to keep this. Differential Revision: https://phabricator.services.mozilla.com/D116813
241321e3830544532bdde13b62974c6fc6635019: Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:35 +0000 - rev 582438
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Wait for all pending tasks to run when shutting down r=sfink This also renames the waitForAllThreads method to the more accurate waitForAllTasks. Differential Revision: https://phabricator.services.mozilla.com/D117005
81b9dab609f66b71f66422c8bb33b5110dd0eb55: Bug 1713335 - Shutdown helper thread system with lock held r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:34 +0000 - rev 582437
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Shutdown helper thread system with lock held r=sfink This allows any external tasks that happen to run after the helper thread system has shut down to correctly detect that. This shouldn't happen with the next patch but it seems safer to do it this way. Differential Revision: https://phabricator.services.mozilla.com/D117004
b6e426c592ae000940c2f4eb2f532038e6f48026: Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:34 +0000 - rev 582436
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Dispatch tasks to external thread pool if present r=sfink Tasks are dispatched by queueing a generic task for the pool. When this is executed it will run the highest priority task pending, if any. In a busy system it's possible that there will be some delay between dispatching this task and it starting running. There is also a limit on the number of tasks that are run at once for each task kind. The patch therefore limits the number of tasks dispatched to the number of avilable threads. Differential Revision: https://phabricator.services.mozilla.com/D116817
996dad41f69b1bdfaffec2a0154633d616b1f18c: Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:34 +0000 - rev 582435
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Split out methods to check whether there any tasks we can run of each kind r=sfink Differential Revision: https://phabricator.services.mozilla.com/D116816
1fe10e4614058616e7574ac385b17f5aacaed7cf: Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:33 +0000 - rev 582434
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Tidy GlobalHelperThreadState::findHighestPriorityTask to use this rather than the global r=sfink I missed this when moving findHighestPriorityTask out of HelperThread previously. Differential Revision: https://phabricator.services.mozilla.com/D116815
fbc9b15ecc8f5492525ceaf96ccd9cfadda9f9b6: Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:33 +0000 - rev 582433
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Use HelperThreadState::isInitialized instead of CanUseExtraThreads in a few places r=sfink This is a stronger condition because we assert CanUseExtraThreads during initialization. It's also closer to to the original intent. Differential Revision: https://phabricator.services.mozilla.com/D116814
321c6ab4a6a965d133b6522e943b49fe37c67157: Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Jun 2021 11:37:32 +0000 - rev 582432
Push 38527 by ncsoregi@mozilla.com at Thu, 10 Jun 2021 03:46:06 +0000
Bug 1713335 - Rely on the embedding to chose whether to use an external pool r=sfink The previous patch added a pref to control use of the external thread pool. I don't think we need an environment variable as well, although I could be persuaded to keep this. Differential Revision: https://phabricator.services.mozilla.com/D116813
3061d812f68ad4fe4102f957a3dabfc0579b9ccd: Bug 1714561 - Allow single-zone JS holders to contain pointers into the atoms zone r=mccr8,sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 07 Jun 2021 15:19:29 +0000 - rev 582087
Push 38520 by malexandru@mozilla.com at Mon, 07 Jun 2021 21:46:37 +0000
Bug 1714561 - Allow single-zone JS holders to contain pointers into the atoms zone r=mccr8,sfink Differential Revision: https://phabricator.services.mozilla.com/D116848
55601e9cd724f246c4bcaa0bedaae69ca5caf03a: Bug 1704923 - Take account of thread count in concurrent task limits r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 10:24:13 +0000 - rev 581819
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Take account of thread count in concurrent task limits r=sfink Currently the calculation of the maximum number of tasks for each kind assumes that thread count is greater than or equal to CPU count. When using an external thread pool that will no longer hold. To maintian the same behaviour we should change those limits that use the currently more restrictive CPU limit to also take the thread count limit into account. Differential Revision: https://phabricator.services.mozilla.com/D116619
0ad1cec01d7b5e3878ea4a64bc977d2c240a87d3: Bug 1704923 - Pass the number of threads when setting up an external thread pool r=sfink,bas
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 10:24:13 +0000 - rev 581818
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Pass the number of threads when setting up an external thread pool r=sfink,bas The JS helper thread system needs to know how many threads are available, in particular because parallel Wasm compilation needs at least two threads to avoid deadlock. This adds a method to get the count from TaskController and passes it through to the JS engine when setting up the thread pool. Differential Revision: https://phabricator.services.mozilla.com/D116220
933c184400836d7e571ccc4371e8d6fae236d42c: Bug 1704923 - Move helper thread APIs to their own header file r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 10:24:12 +0000 - rev 581817
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Move helper thread APIs to their own header file r=sfink This also tidies up the implementation a bit, moving SetHelperThreadTaskCallback to the JS namespace and removing the unused RunnableTask class. Differential Revision: https://phabricator.services.mozilla.com/D116219
cf5df28af27756d66eb524b4fbae0782e600b5bc: Bug 1704923 - Update HelperThreadTaskCallback to remove task parameter r=sfink,KrisWright
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 10:24:12 +0000 - rev 581816
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Update HelperThreadTaskCallback to remove task parameter r=sfink,KrisWright When the task runs it JS::RunHelperThreadTask to perform the work. Differential Revision: https://phabricator.services.mozilla.com/D112752
498f9f3927f9e4c8a64a6f525d5813e50a2925a5: Bug 1704923 - Take account of thread count in concurrent task limits r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 07:31:31 +0000 - rev 581802
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Take account of thread count in concurrent task limits r=sfink Currently the calculation of the maximum number of tasks for each kind assumes that thread count is greater than or equal to CPU count. When using an external thread pool that will no longer hold. To maintian the same behaviour we should change those limits that use the currently more restrictive CPU limit to also take the thread count limit into account. Differential Revision: https://phabricator.services.mozilla.com/D116619
9eabc7fc9b81be0b4600202d4916bab1a021a0dd: Bug 1704923 - Pass the number of threads when setting up an external thread pool r=sfink,bas
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 03 Jun 2021 07:31:31 +0000 - rev 581801
Push 38513 by abutkovits@mozilla.com at Fri, 04 Jun 2021 10:21:11 +0000
Bug 1704923 - Pass the number of threads when setting up an external thread pool r=sfink,bas The JS helper thread system needs to know how many threads are available, in particular because parallel Wasm compilation needs at least two threads to avoid deadlock. This adds a method to get the count from TaskController and passes it through to the JS engine when setting up the thread pool. Differential Revision: https://phabricator.services.mozilla.com/D116220