searching for reviewer(sfink)
eee37f3bfaba651c3625e9e6288fa0130e2eec1f: Bug 1800263 - Part 5: Tidyup GCMarker interface and make methods private where possible r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 23 Nov 2022 17:38:06 +0000 - rev 643378
Push 40428 by sstanca@mozilla.com at Thu, 24 Nov 2022 09:32:51 +0000
Bug 1800263 - Part 5: Tidyup GCMarker interface and make methods private where possible r=sfink This class has become pretty complicated. I've tried to reorder the methods in a way that groups related methods together and to make methods private where possible. Differential Revision: https://phabricator.services.mozilla.com/D162397
beeb51f05f78f6219f93f8ac785c03c46a3f919f: Bug 1800263 - Part 4: Push marking options through markAndTraverse to avoid setting the flag for things we've already marked r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 23 Nov 2022 17:38:06 +0000 - rev 643377
Push 40428 by sstanca@mozilla.com at Thu, 24 Nov 2022 09:32:51 +0000
Bug 1800263 - Part 4: Push marking options through markAndTraverse to avoid setting the flag for things we've already marked r=sfink As a further optimisation we can move the flag update into GCMarker::markAndTraverse so we don't set the flag for thing we've already marked. Differential Revision: https://phabricator.services.mozilla.com/D162396
ba6cf596552d533564e66419e2967e3f652de91e: Bug 1800263 - Part 3: Add a root marking mode with its own tracer r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 23 Nov 2022 17:38:06 +0000 - rev 643376
Push 40428 by sstanca@mozilla.com at Thu, 24 Nov 2022 09:32:51 +0000
Bug 1800263 - Part 3: Add a root marking mode with its own tracer r=sfink This adds a new marking mode for root marking and templates MarkingTracer on a options bitmask. The GCMarker's tracer becomes a variant and we change the constructed variant when the mode changes. The templating allows us to make parts of the marking path conditional using if constexpr on the marking options. Differential Revision: https://phabricator.services.mozilla.com/D162395
969822745d98b0f9a30b79dfc2d62988b6dddcc9: Bug 1800263 - Part 2: Add MarkingTracer as a member of GCMarker r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 23 Nov 2022 17:38:05 +0000 - rev 643375
Push 40428 by sstanca@mozilla.com at Thu, 24 Nov 2022 09:32:51 +0000
Bug 1800263 - Part 2: Add MarkingTracer as a member of GCMarker r=sfink Previously GCMarker was a JSTracer. This separates out the impelmentation of the tracer interface into another class. The idea here is that we will change the tracer class used in different phases of the GC. This will allow us to skip setting this compartment flag outside root marker, and later allow us to select a different way of accessing the mark bits for parallel marking. Differential Revision: https://phabricator.services.mozilla.com/D162394
1bca4e782410368ea6f6aacdd63f69e188bcb4e8: Bug 1800263 - Part 1: Tidup, make MarkingState a private enum inside GCMarker r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 23 Nov 2022 17:38:05 +0000 - rev 643374
Push 40428 by sstanca@mozilla.com at Thu, 24 Nov 2022 09:32:51 +0000
Bug 1800263 - Part 1: Tidup, make MarkingState a private enum inside GCMarker r=sfink Differential Revision: https://phabricator.services.mozilla.com/D162393
3cbb5b420782299b9774dd019e9f9b237ef48186: Bug 1799824 part 2 - Support more GC things in shortestPaths testing function. r=sfink
Jan de Mooij <jdemooij@mozilla.com> - Mon, 21 Nov 2022 14:58:19 +0000 - rev 643012
Push 40422 by ncsoregi@mozilla.com at Tue, 22 Nov 2022 09:46:06 +0000
Bug 1799824 part 2 - Support more GC things in shortestPaths testing function. r=sfink While we're here, it's easy to add support for other GC things like `BigInt`. Depends on D161767 Differential Revision: https://phabricator.services.mozilla.com/D161768
9b556358055758646ac3cdf6d50a2aee63c00fb6: Bug 1799824 part 1 - Check array elements after potential side-effects in shortestPaths testing function. r=sfink
Jan de Mooij <jdemooij@mozilla.com> - Mon, 21 Nov 2022 14:58:19 +0000 - rev 643011
Push 40422 by ncsoregi@mozilla.com at Tue, 22 Nov 2022 09:46:06 +0000
Bug 1799824 part 1 - Check array elements after potential side-effects in shortestPaths testing function. r=sfink Differential Revision: https://phabricator.services.mozilla.com/D161767
8d53a949ed1a42e3b014455e67dea4e3786d3511: Bug 1801076 - Increase small heap incremental limit r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 17 Nov 2022 17:56:08 +0000 - rev 642673
Push 40413 by csabou@mozilla.com at Fri, 18 Nov 2022 04:18:45 +0000
Bug 1801076 - Increase small heap incremental limit r=sfink This change to delay reaching the GC urgent threshold while the heap is small improved our Jetstream2 score by 2% on MacOS in testing. Differential Revision: https://phabricator.services.mozilla.com/D162282
a140341548916ef553ec4bfd5e9a92b60c355a69: Bug 1693223 - Fix gray marking assertions in ProxyObject::setPrivate r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 15 Nov 2022 20:07:16 +0000 - rev 642495
Push 40408 by nfay@mozilla.com at Wed, 16 Nov 2022 09:31:06 +0000
Bug 1693223 - Fix gray marking assertions in ProxyObject::setPrivate r=sfink Currently this doesn't take account of the fact that gray bits may not be corrent during incremental GC. The provided API function handles this. Differential Revision: https://phabricator.services.mozilla.com/D162099
171adcc24e6349355763856e63e3a3552f81f58a: Bug 1800492 - Fix division by zero when calculating GC_TENURED_SURVIVAL_RATE telemetry r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 15 Nov 2022 09:55:17 +0000 - rev 642433
Push 40406 by abutkovits@mozilla.com at Tue, 15 Nov 2022 16:44:51 +0000
Bug 1800492 - Fix division by zero when calculating GC_TENURED_SURVIVAL_RATE telemetry r=sfink Differential Revision: https://phabricator.services.mozilla.com/D162016
0857304e41340efdad42d8f1c78d0a0206491b5c: Bug 1799678 - Fix assertion that assumed it could be only happen on the main thread r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 09 Nov 2022 09:37:00 +0000 - rev 640787
Push 40391 by imoraru@mozilla.com at Thu, 10 Nov 2022 04:48:58 +0000
Bug 1799678 - Fix assertion that assumed it could be only happen on the main thread r=sfink JS::RuntimeHeapIsMinorCollecting() gets the JSContext from TLS, but IsMarkedInternal() can be called from a helper thread where this is null. Differential Revision: https://phabricator.services.mozilla.com/D161611
9eecdc998da7ebaaebca1bbc784a1b1e52883979: Bug 1798284 part 3 - Use a non-atomic load for HeaderWord::get. r=sfink
Jan de Mooij <jdemooij@mozilla.com> - Wed, 02 Nov 2022 13:22:55 +0000 - rev 640019
Push 40370 by imoraru@mozilla.com at Wed, 02 Nov 2022 17:43:50 +0000
Bug 1798284 part 3 - Use a non-atomic load for HeaderWord::get. r=sfink This improves GCC/Clang compiler optimizations. For example, when checking if an object has `JSClass` `A` or `B` with `obj->is<A>() || obj->is<B>()`, the compiler is now able to fold the redundant `obj->shape->base->clasp` loads. Differential Revision: https://phabricator.services.mozilla.com/D160793
0abb6e44411ffe79841d43149d5b7e2a58b241dc: Bug 1798284 part 2 - Use __atomic intrinsics for loading/storing the header word. r=sfink
Jan de Mooij <jdemooij@mozilla.com> - Wed, 02 Nov 2022 12:14:30 +0000 - rev 640012
Push 40370 by imoraru@mozilla.com at Wed, 02 Nov 2022 17:43:50 +0000
Bug 1798284 part 2 - Use __atomic intrinsics for loading/storing the header word. r=sfink Because all accesses go through `getAtomic` or `setAtomic`, this should have no change in behavior. Differential Revision: https://phabricator.services.mozilla.com/D160792
78e7851f1978503ca34a27a76b2e2b9af245e91f: Bug 1798284 part 1 - Add a HeaderWord class for the Cell header word. r=sfink
Jan de Mooij <jdemooij@mozilla.com> - Wed, 02 Nov 2022 12:14:29 +0000 - rev 640011
Push 40370 by imoraru@mozilla.com at Wed, 02 Nov 2022 17:43:50 +0000
Bug 1798284 part 1 - Add a HeaderWord class for the Cell header word. r=sfink This refactors accesses of the Cell's header word to go through a small set of methods. This makes it easier to assert invariants and also lets us make some of these operations non-atomic in later patches. Differential Revision: https://phabricator.services.mozilla.com/D160791
5fa2ef9fb2f60fb8370a3b210e6f3d585c65b107: Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 15:17:43 +0000 - rev 639639
Push 40356 by nbeleuzu@mozilla.com at Sat, 29 Oct 2022 09:50:10 +0000
Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink Currently we initialize the mark stack to a different size depending on whether or not incremental GC is enable. However, after the first GC we always shrink it to the initial size when it is disabled. This bug shows that there's no point having separate sizes so this patch removes the option and uses a single size regardless. Differential Revision: https://phabricator.services.mozilla.com/D160528
453aa2faad97ce68b33bef75cd232e37d759556e: Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 15:17:43 +0000 - rev 639638
Push 40356 by nbeleuzu@mozilla.com at Sat, 29 Oct 2022 09:50:10 +0000
Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink Currently we have a GC parameter that allows setting a maximum mark stack capacity. This is only ever used by test code, not in the browser. This requires extra unnecessary work in release builds if we move to a different stack representation as we won't be able to fold the comparison into the current capacity check as we do now. The patch makes this feature condtional on JS_GC_ZEAL. Depends on D160526 Differential Revision: https://phabricator.services.mozilla.com/D160527
d33708e4f8ecd98a449df50766a2ea59045b317f: Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 15:17:43 +0000 - rev 639637
Push 40356 by nbeleuzu@mozilla.com at Sat, 29 Oct 2022 09:50:10 +0000
Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink Differential Revision: https://phabricator.services.mozilla.com/D160526
967fd2ce6f67b87426c0878cac53d461165ca1f1: Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 15:17:42 +0000 - rev 639636
Push 40356 by nbeleuzu@mozilla.com at Sat, 29 Oct 2022 09:50:10 +0000
Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink Currently the way mark colors work for delayed marking doesn't align with normal marking for gray marking of GC things that can only be marked black (e.g. strings). Normal marking keeps these on the gray mark stack, but when it comes to mark them they are marked black. Currently OOM during marking pushes arenas containing such GC things onto the delayed black marking list. This means that gray marking can cause delayed black marking. This is surprising and an unnecessarily additional complication. The patch makes this work the same as normal marking. OOM during gray marking always pushes arenas onto the gray marking list; arenas on the gray marking list are marked black if they are a GC thing kind that cannot be marked gray. Depends on D160524 Differential Revision: https://phabricator.services.mozilla.com/D160525
cf090cf39fadeaefe73229499a1384a5145fc9c2: Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 15:17:42 +0000 - rev 639635
Push 40356 by nbeleuzu@mozilla.com at Sat, 29 Oct 2022 09:50:10 +0000
Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink Parallel marking will use one GCMarker per thread. The testing mark queue is really a per-runtime data structure, so this patch moves it to the GCRuntime. Differential Revision: https://phabricator.services.mozilla.com/D160524
7cda151d97a53e47a1f526390dbb005ba8f78fca: Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 09:47:15 +0000 - rev 639599
Push 40355 by smolnar@mozilla.com at Fri, 28 Oct 2022 21:22:11 +0000
Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink Currently we initialize the mark stack to a different size depending on whether or not incremental GC is enable. However, after the first GC we always shrink it to the initial size when it is disabled. This bug shows that there's no point having separate sizes so this patch removes the option and uses a single size regardless. Differential Revision: https://phabricator.services.mozilla.com/D160528
098569654f17fe958cfa7ca7077e4d770044a62e: Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 09:47:14 +0000 - rev 639598
Push 40355 by smolnar@mozilla.com at Fri, 28 Oct 2022 21:22:11 +0000
Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink Currently we have a GC parameter that allows setting a maximum mark stack capacity. This is only ever used by test code, not in the browser. This requires extra unnecessary work in release builds if we move to a different stack representation as we won't be able to fold the comparison into the current capacity check as we do now. The patch makes this feature condtional on JS_GC_ZEAL. Depends on D160526 Differential Revision: https://phabricator.services.mozilla.com/D160527
6e5a935e576a5263c85c48b7c39450464b2b047e: Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 09:47:14 +0000 - rev 639597
Push 40355 by smolnar@mozilla.com at Fri, 28 Oct 2022 21:22:11 +0000
Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink Depends on D160525 Differential Revision: https://phabricator.services.mozilla.com/D160526
eb109d0ce408bda7631874511bddc204165023cd: Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 09:47:14 +0000 - rev 639596
Push 40355 by smolnar@mozilla.com at Fri, 28 Oct 2022 21:22:11 +0000
Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink Currently the way mark colors work for delayed marking doesn't align with normal marking for gray marking of GC things that can only be marked black (e.g. strings). Normal marking keeps these on the gray mark stack, but when it comes to mark them they are marked black. Currently OOM during marking pushes arenas containing such GC things onto the delayed black marking list. This means that gray marking can cause delayed black marking. This is surprising and an unnecessarily additional complication. The patch makes this work the same as normal marking. OOM during gray marking always pushes arenas onto the gray marking list; arenas on the gray marking list are marked black if they are a GC thing kind that cannot be marked gray. Depends on D160524 Differential Revision: https://phabricator.services.mozilla.com/D160525
186a012563fc5fa63ca8bca17ce517e35787a675: Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Fri, 28 Oct 2022 09:47:13 +0000 - rev 639595
Push 40355 by smolnar@mozilla.com at Fri, 28 Oct 2022 21:22:11 +0000
Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink Parallel marking will use one GCMarker per thread. The testing mark queue is really a per-runtime data structure, so this patch moves it to the GCRuntime. Differential Revision: https://phabricator.services.mozilla.com/D160524
8399201e3b089285204de34fa7084b4888013534: Bug 1774302 - Fix unrooted return value in VideoFrame deserialization r=sfink
Chun-Min Chang <chun.m.chang@gmail.com> - Thu, 27 Oct 2022 23:51:07 +0000 - rev 639556
Push 40354 by sstanca@mozilla.com at Fri, 28 Oct 2022 09:44:53 +0000
Bug 1774302 - Fix unrooted return value in VideoFrame deserialization r=sfink To avoid an rooting hazard error from returning a raw JSObject* before running the RefPtr<VidoeFrame>'s destructor, the RefPtr<VideoFrame> needs to be destroyed before returning the raw JSObject* Differential Revision: https://phabricator.services.mozilla.com/D160561
27d9b7db5e1c50af9456023d63e2d3db72b48df2: Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 27 Oct 2022 18:23:03 +0000 - rev 639506
Push 40353 by ctuns@mozilla.com at Fri, 28 Oct 2022 04:43:55 +0000
Bug 1797755 - Part 5: Use a single initial mark stack size regardless of whether incremental GC is enabled r=sfink Currently we initialize the mark stack to a different size depending on whether or not incremental GC is enable. However, after the first GC we always shrink it to the initial size when it is disabled. This bug shows that there's no point having separate sizes so this patch removes the option and uses a single size regardless. Depends on D160527 Differential Revision: https://phabricator.services.mozilla.com/D160528
f207beed6252d85e5a64cc768eaef9d8a47b4912: Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 27 Oct 2022 18:23:03 +0000 - rev 639505
Push 40353 by ctuns@mozilla.com at Fri, 28 Oct 2022 04:43:55 +0000
Bug 1797755 - Part 4: Remove option to set maximum mark stack capacity in release builds r=sfink Currently we have a GC parameter that allows setting a maximum mark stack capacity. This is only ever used by test code, not in the browser. This requires extra unnecessary work in release builds if we move to a different stack representation as we won't be able to fold the comparison into the current capacity check as we do now. The patch makes this feature condtional on JS_GC_ZEAL. Depends on D160526 Differential Revision: https://phabricator.services.mozilla.com/D160527
4746d15d7a9fa501c702bd1437d3f3da127a86ee: Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 27 Oct 2022 18:23:03 +0000 - rev 639504
Push 40353 by ctuns@mozilla.com at Fri, 28 Oct 2022 04:43:55 +0000
Bug 1797755 - Part 3: Remove the unused MarkStackIter class r=sfink Depends on D160525 Differential Revision: https://phabricator.services.mozilla.com/D160526
8be86d9e2f186c5c34a6c572bdec07ba13c7d9a6: Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 27 Oct 2022 18:23:02 +0000 - rev 639503
Push 40353 by ctuns@mozilla.com at Fri, 28 Oct 2022 04:43:55 +0000
Bug 1797755 - Part 2: Make delayed marking colors work like normal marking r=sfink Currently the way mark colors work for delayed marking doesn't align with normal marking for gray marking of GC things that can only be marked black (e.g. strings). Normal marking keeps these on the gray mark stack, but when it comes to mark them they are marked black. Currently OOM during marking pushes arenas containing such GC things onto the delayed black marking list. This means that gray marking can cause delayed black marking. This is surprising and an unnecessarily additional complication. The patch makes this work the same as normal marking. OOM during gray marking always pushes arenas onto the gray marking list; arenas on the gray marking list are marked black if they are a GC thing kind that cannot be marked gray. Depends on D160524 Differential Revision: https://phabricator.services.mozilla.com/D160525
9a3821fa6bb88b90860159e942365038485fb060: Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 27 Oct 2022 18:23:02 +0000 - rev 639502
Push 40353 by ctuns@mozilla.com at Fri, 28 Oct 2022 04:43:55 +0000
Bug 1797755 - Part 1: Move testing mark queue to GCRuntime r=sfink Parallel marking will use one GCMarker per thread. The testing mark queue is really a per-runtime data structure, so this patch moves it to the GCRuntime. Differential Revision: https://phabricator.services.mozilla.com/D160524
894ad5982bff38a17909b61323273417a4662650: Bug 1796081 - Part 2: Only check the key color once when populating the ephemeron table r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 20 Oct 2022 08:10:29 +0000 - rev 638427
Push 40335 by imoraru@mozilla.com at Thu, 20 Oct 2022 21:51:26 +0000
Bug 1796081 - Part 2: Only check the key color once when populating the ephemeron table r=sfink Currently the table population is done separately from marking the entry which means we check the key color twice, potentially getting different results if another thread is marking at the same time. This could result in us not adding ephemeron table entries when necessary. The patch consolidates these two paths. Depends on D159677 Differential Revision: https://phabricator.services.mozilla.com/D159678
c7898b0dbad3c3b6098d3df4e18938978b671547: Bug 1796081 - Part 1: Don't trace weak map values that are in the nursery r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 20 Oct 2022 08:10:28 +0000 - rev 638426
Push 40335 by imoraru@mozilla.com at Thu, 20 Oct 2022 21:51:26 +0000
Bug 1796081 - Part 1: Don't trace weak map values that are in the nursery r=sfink We don't need to trace weakmap values that are in the nursery because these will be kept alive in minor GC by the store buffer entry pushed by HeapPtr. Differential Revision: https://phabricator.services.mozilla.com/D159677
0019a057974bc4ced48db49825a7803b36f5a353: Bug 1795642 - Remove the buffering barrier tracer r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 19 Oct 2022 08:37:56 +0000 - rev 638302
Push 40332 by nfay@mozilla.com at Wed, 19 Oct 2022 21:16:15 +0000
Bug 1795642 - Remove the buffering barrier tracer r=sfink This removes the barrier tracer and marks GC things immediately when barriers fire. This restores the original behaviour before the separate barrier tracer was added. Differential Revision: https://phabricator.services.mozilla.com/D159492
1d74e8b66af55de57634d9f61054ba86bfc6170a: Bug 1795634 - Remove unused WeakMap::markKeys method r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 19 Oct 2022 08:37:18 +0000 - rev 638301
Push 40332 by nfay@mozilla.com at Wed, 19 Oct 2022 21:16:15 +0000
Bug 1795634 - Remove unused WeakMap::markKeys method r=sfink Differential Revision: https://phabricator.services.mozilla.com/D159487
586b7867bbfed5d6389668b9d18d7dc162a9c00b: Bug 1795063 - Stop disabling ASLR in spidermonkey builds from automation, r=sfink
Andrew Halberstadt <ahal@mozilla.com> - Tue, 18 Oct 2022 17:58:18 +0000 - rev 638222
Push 40330 by smolnar@mozilla.com at Wed, 19 Oct 2022 04:09:55 +0000
Bug 1795063 - Stop disabling ASLR in spidermonkey builds from automation, r=sfink Differential Revision: https://phabricator.services.mozilla.com/D159517
4563dd583110be33b4767284f04e1ea83f1a78bc: Bug 1790630 - Add telemetry for zones r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 13 Oct 2022 09:22:38 +0000 - rev 637768
Push 40313 by ncsoregi@mozilla.com at Thu, 13 Oct 2022 15:46:47 +0000
Bug 1790630 - Add telemetry for zones r=sfink This adds telemetry for total zone count and number of zones collected. Differential Revision: https://phabricator.services.mozilla.com/D157302
45c18897ce062e25601e43156435da3b0f46892b: Bug 1792338 - Don't check budget when doing delayed marking work r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 10 Oct 2022 09:40:14 +0000 - rev 637316
Push 40305 by imoraru@mozilla.com at Mon, 10 Oct 2022 21:46:39 +0000
Bug 1792338 - Don't check budget when doing delayed marking work r=sfink This is used to handle OOM when trying to expand the mark stack. This is a fallback to stop us having to crash so I don't think it matters if we overrun our slice budget here. Depends on D158847 Differential Revision: https://phabricator.services.mozilla.com/D158848
6aaaac0e8806db230164dc434c8267e275c42c3e: Bug 1792338 - Don't allow the testing mark queue to mark objects with the wrong color r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Mon, 10 Oct 2022 09:40:14 +0000 - rev 637315
Push 40305 by imoraru@mozilla.com at Mon, 10 Oct 2022 21:46:39 +0000
Bug 1792338 - Don't allow the testing mark queue to mark objects with the wrong color r=sfink The problem here is that that test mark queue can call processMarkStackTop with a different mark color to the top of the mark stack if the object it tries to push is not pushed due to the mark stack exceeding its capacity (e.g. the top of the stack can be gray but markColor() is MarkColor::Black). This ends up with things being marked the wrong color and in this example some things not being marked at all. There was already a check for OOM in processMarkQueue but it assumed that the stack was previously empty, which is not always true. The patch fixes the check and adds some more assertions to guard against this kind of problem. This was the root cause of bug 1791363 too. The fix for that just stopped the mark stack being full in the wrong place. Differential Revision: https://phabricator.services.mozilla.com/D158847
de384dc334c4b86f9735c35e745230c8fe9ee785: Bug 1792159 - Add missing includes to AtomicOperationsGenerated.h r=sfink
Ted Campbell <tcampbell@mozilla.com> - Wed, 05 Oct 2022 16:18:42 +0000 - rev 636995
Push 40290 by ncsoregi@mozilla.com at Wed, 05 Oct 2022 21:51:13 +0000
Bug 1792159 - Add missing includes to AtomicOperationsGenerated.h r=sfink On certain build configurations involving GCC, we use additional annotations that are defined in Attributes.h so we must include the header first. For consistency, include on all platforms since we use this header safely in many places already. Differential Revision: https://phabricator.services.mozilla.com/D158595
57a896ea3efbcdb934412e1a929fa9b74b1c210f: Bug 1792504 - Don't check gray mark bits for types that are never marked gray r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 28 Sep 2022 21:16:12 +0000 - rev 636585
Push 40274 by apavel@mozilla.com at Thu, 29 Sep 2022 09:39:14 +0000
Bug 1792504 - Don't check gray mark bits for types that are never marked gray r=sfink This adds a new header gc/TraceKind.h which contains definitions related to TraceKind that aren't required outside of the engine. Differential Revision: https://phabricator.services.mozilla.com/D158208
04b1663a5ed94f75ebde93077ca2065b9d0a8842: Bug 1791887 - Remove timing assertion that doesn't always hold r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Thu, 22 Sep 2022 16:22:03 +0000 - rev 636102
Push 40258 by ctuns@mozilla.com at Thu, 22 Sep 2022 21:44:29 +0000
Bug 1791887 - Remove timing assertion that doesn't always hold r=sfink There's a comment below that says that we occasionally observe collector time being larger than total time, so it's not safe to assert this. Differential Revision: https://phabricator.services.mozilla.com/D157919
4c043a955561bfc5ba18aea75489f23309989071: Bug 1791547 - Enable balanced heap limits by default r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 21 Sep 2022 08:40:08 +0000 - rev 635956
Push 40254 by mlaza@mozilla.com at Wed, 21 Sep 2022 21:43:38 +0000
Bug 1791547 - Enable balanced heap limits by default r=sfink This is not enable for fuzzing builds or in the shell if the fuzzing safe option is passed. Differential Revision: https://phabricator.services.mozilla.com/D157723
c0fe58fee4552f08a0390478bbe04830890ca1b6: Bug 1791363 - Rename GCMarker::color to avoid confusion with local variables r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 21 Sep 2022 08:37:14 +0000 - rev 635954
Push 40254 by mlaza@mozilla.com at Wed, 21 Sep 2022 21:43:38 +0000
Bug 1791363 - Rename GCMarker::color to avoid confusion with local variables r=sfink It's pretty confusing that this name is sometimes used for local variables and sometimes refers to the current mark color. Depends on D157733 Differential Revision: https://phabricator.services.mozilla.com/D157734
882c2a4dde59cd781adfcea3c6501da71aa9e2d2: Bug 1791363 - Process newly added marking work after performing delayed marking r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 21 Sep 2022 08:37:14 +0000 - rev 635953
Push 40254 by mlaza@mozilla.com at Wed, 21 Sep 2022 21:43:38 +0000
Bug 1791363 - Process newly added marking work after performing delayed marking r=sfink Delayed marking may push more (normal, non-delayed) marking work. We need to do this before switch mark color from black to gray since we cannot add gray marking work while there is black marking work on the stack. Differential Revision: https://phabricator.services.mozilla.com/D157733
7912bdbd18424ac1bdefae567a211991c0626cec: Bug 1722406 - Add more assertions that GC parallel task lists are synchronized correctly r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 20 Sep 2022 09:08:12 +0000 - rev 635838
Push 40252 by imoraru@mozilla.com at Wed, 21 Sep 2022 03:56:08 +0000
Bug 1722406 - Add more assertions that GC parallel task lists are synchronized correctly r=sfink This seems to be crashing when LinkedList::sizeOfExcludingThis traverses the helper thread system's list of GC parallel tasks. The patch restricts the interfaces of the relevant classes to help enforce synchronization (without finding any issues) and adds more assertions (which may yet find something). Differential Revision: https://phabricator.services.mozilla.com/D157500
8f6afc5740f5301a518fc096013f6065514e529a: Bug 1791056 - Update module owner metadata for sfink. r=sfink,zeid
Ted Campbell <tcampbell@mozilla.com> - Mon, 19 Sep 2022 12:49:02 +0000 - rev 635752
Push 40250 by abutkovits@mozilla.com at Tue, 20 Sep 2022 03:38:59 +0000
Bug 1791056 - Update module owner metadata for sfink. r=sfink,zeid Use the correct Bugzilla ID that is tied to phabricator. Depends on D157502 Differential Revision: https://phabricator.services.mozilla.com/D157503
a0110fc4a82eefde5d6fc6f8bcc3ffe3c13baf68: Bug 1790336 - Part 2: Increase balanced heap growth factor r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 14 Sep 2022 08:50:32 +0000 - rev 635488
Push 40235 by mlaza@mozilla.com at Wed, 14 Sep 2022 15:48:03 +0000
Bug 1790336 - Part 2: Increase balanced heap growth factor r=sfink Increasing this parameter gives us parity on our benchmarks in the testing I've done so far. Differential Revision: https://phabricator.services.mozilla.com/D157095
93bf49a3911b979c3436a796e9fc9850645423fe: Bug 1790336 - Part 1: Limit heap growth to sensible limit r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 14 Sep 2022 08:50:32 +0000 - rev 635487
Push 40235 by mlaza@mozilla.com at Wed, 14 Sep 2022 15:48:03 +0000
Bug 1790336 - Part 1: Limit heap growth to sensible limit r=sfink This limits the heap growth when using balanced heap limits to a factor of 3. This allows increasing the heap growth factor so the heap can grow rapidly when where is a lot of allocation happening without affecting memory use too badly. Differential Revision: https://phabricator.services.mozilla.com/D157094
f75227f692f8a97492002f091f3a103237f28aa1: Bug 1790426 - Don't evict the nursery when freezing the shared atoms zone r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 13 Sep 2022 18:03:29 +0000 - rev 635397
Push 40234 by smolnar@mozilla.com at Wed, 14 Sep 2022 04:09:22 +0000
Bug 1790426 - Don't evict the nursery when freezing the shared atoms zone r=sfink By default iterating the cells in a zone will evict the nursery for nursery-allocatable thing kinds. Passing AutoAssertEmptyNursery disableds this. Differential Revision: https://phabricator.services.mozilla.com/D157125
81fd7885f1810e64eda9c1db031b0af34a62a44e: Bug 1785804 - Part 6: Inline TraceEdge methods for non-tagged pointers r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Wed, 07 Sep 2022 09:49:59 +0000 - rev 634789
Push 40216 by ccozmuta@mozilla.com at Thu, 08 Sep 2022 04:52:24 +0000
Bug 1785804 - Part 6: Inline TraceEdge methods for non-tagged pointers r=sfink For non-tagged pointer types, DoCallback is now simple enough that we can define this inline in Tracing.h and most TraceEdge methods become a virtual method call. Depends on D156563 Differential Revision: https://phabricator.services.mozilla.com/D156564