searching for reviewer(jonco)
5decb743461a478278ee42d9c54c24b939db9d59: Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco
Steve Fink <sfink@mozilla.com> - Fri, 15 Nov 2019 16:40:44 +0000 - rev 502234
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51492
ba1518c4b5e817c3cce93185afc5cebf3092dfde: Bug 1594054 - Move ExecutableAllocator from JitRuntime to JitZone. r=jonco,erahm
Jan de Mooij <jdemooij@mozilla.com> - Thu, 14 Nov 2019 10:20:02 +0000 - rev 501914
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1594054 - Move ExecutableAllocator from JitRuntime to JitZone. r=jonco,erahm This matches the JitCode GC-thing lifetime and will hopefully help avoid fragmentation. Differential Revision: https://phabricator.services.mozilla.com/D52823
8daa186bd18b8a894f95e22f32c9ecc45481553a: Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco
Steve Fink <sfink@mozilla.com> - Tue, 12 Nov 2019 22:24:29 +0000 - rev 501658
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51492
de7a1a1b75f0262d707f0a6045110fc71236d9f3: Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco
Steve Fink <sfink@mozilla.com> - Tue, 12 Nov 2019 19:54:06 +0000 - rev 501632
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1593399 - Rework how mark colors are handled in weakmap marking r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51492
b78631b2bccdd0b08e3b701c88b03088a7823701: Bug 1592992 - Part 19: Move jsutil.cpp to util/Utility.cpp. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 13:24:15 +0000 - rev 501271
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 19: Move jsutil.cpp to util/Utility.cpp. r=jonco This file provides the implementation of js/Utility.h, so it should be renamed to match the header name. Differential Revision: https://phabricator.services.mozilla.com/D51378
75f180647de362e3673d5fb9f19efeaecc14213e: Bug 1592992 - Part 18: Remove jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:09:57 +0000 - rev 501270
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 18: Remove jsutil.h. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51377
e7051eca20f58f94b68a371bb9ec2f795049e03f: Bug 1592992 - Part 17: Remove includes for jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:09:40 +0000 - rev 501269
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 17: Remove includes for jsutil.h. r=jonco And handle the fallout of missing #includes when compiling a non-unified build. Differential Revision: https://phabricator.services.mozilla.com/D51376
1f4c3e6e6c7e5032c043c78fb9710152b07b929f: Bug 1592992 - Part 16: Include util/DiagnosticAssertions.h where necessary. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:08:52 +0000 - rev 501268
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 16: Include util/DiagnosticAssertions.h where necessary. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51375
c29e5c442d0ee579ae0338e661f45a0c89191450: Bug 1592992 - Part 15: Include util/Poison.h where necessary. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:08:29 +0000 - rev 501267
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 15: Include util/Poison.h where necessary. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51374
70f5608fb8f28689ab0a2331b63e0596aacc6fff: Bug 1592992 - Part 14: Include util/Memory.h where necessary. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:08:01 +0000 - rev 501266
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 14: Include util/Memory.h where necessary. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51373
6f9ec747d5b61825464b378cec980546aab79805: Bug 1592992 - Part 13: Include util/BitArray.h where necessary. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:07:21 +0000 - rev 501265
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 13: Include util/BitArray.h where necessary. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51372
879358fd177136a5989b627dd297957065c12105: Bug 1592992 - Part 12: Replace js::Min/Max with std::min/max. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:06:58 +0000 - rev 501264
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 12: Replace js::Min/Max with std::min/max. r=jonco For the most part another mechanical change, except for two changes: - In gc/Nursery.cpp and vm/DateTime.cpp, the initializer_list variants for std::min/max are used, because the two parameter forms of min/max take const reference parameters. And it's not possible to take the reference of a constexpr variable which wasn't previously explicitly defined. This is just a C++14 limitation and as soon as we compile with C++17, we can revert this change. - builtin/String.cpp was calling `Max(unsignedVar, 0U)` in a few places, which led to compiler warnings, because the result is always `unsignedVar`. Differential Revision: https://phabricator.services.mozilla.com/D51371
2df8363a5d34e7972e18d63cec98109979207606: Bug 1592992 - Part 11: Remove no longer needed includes from jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:06:00 +0000 - rev 501263
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 11: Remove no longer needed includes from jsutil.h. r=jonco The includes are still transitively reachable through the new "#include util/*.h" headers. Differential Revision: https://phabricator.services.mozilla.com/D51370
e6fb5e9d00f45ad3b5bfb0b7f8df77ef63ecb3d6: Bug 1592992 - Part 10: Split diagnostic assertions from jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:05:41 +0000 - rev 501262
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 10: Split diagnostic assertions from jsutil.h. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51369
c7eee900c240c23c96ac884d00f87f751cf6fc1c: Bug 1592992 - Part 9: Move js::IsInitialized() into its sole caller. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:05:23 +0000 - rev 501261
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 9: Move js::IsInitialized() into its sole caller. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51368
ab4ac2b0cb6e13797d9891b9f5bdef2b70e0996f: Bug 1592992 - Part 8: Split memory and byte alignment functions from jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:05:16 +0000 - rev 501260
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 8: Split memory and byte alignment functions from jsutil.h. r=jonco A single header for both memory and byte alignment functions, similar to the standard <memory> header, which also provides memory and byte alignment related functionality. Differential Revision: https://phabricator.services.mozilla.com/D51367
3b7daea3fbf06f23537345b8b9b34820f8bcb62a: Bug 1592992 - Part 7: Split bit-array functions from jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:05:14 +0000 - rev 501259
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 7: Split bit-array functions from jsutil.h. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51366
212c71d3ed1c291910d22c822f0752d1a2d578f2: Bug 1592992 - Part 6: Split poisoning functions from jsutil.h. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:04:14 +0000 - rev 501258
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 6: Split poisoning functions from jsutil.h. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51365
3d592f96e69a06ec7b7d4cffc6ccc07dbd659f59: Bug 1592992 - Part 5: Replace js::Reverse with std::reverse. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:03:52 +0000 - rev 501257
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 5: Replace js::Reverse with std::reverse. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51364
aeed2e27a9bd5e03ab9d2557933ebe60e2e7888a: Bug 1592992 - Part 4: Replace js::EqualContainers with std::equal. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:03:32 +0000 - rev 501256
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 4: Replace js::EqualContainers with std::equal. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51363
01b3529c554e9d4a7e7497dc1897c23f515aa654: Bug 1592992 - Part 3: Replace js::EraseIf with Vector::eraseIf where possible. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:03:05 +0000 - rev 501255
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 3: Replace js::EraseIf with Vector::eraseIf where possible. r=jonco mozilla::Vector already provides an `eraseIf` method, so we should prefer to use the existing method. Except that Vector::eraseIf doesn't return the number of elements removed, but that's easy to determine manually. More annoyingly is the use of a modifying predicate function in Zone.cpp, which prevents using Vector::eraseIf. It looks like for that specific use case a custome `EraseIf` function is still necessary. Differential Revision: https://phabricator.services.mozilla.com/D51362
39d4f511997aad7d3f138fdcdaa9b846e2ab50f7: Bug 1592992 - Part 2: Replace js::Find with std::find. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:02:42 +0000 - rev 501254
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 2: Replace js::Find with std::find. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51361
3cd1ccce483f7f5be21da8a1edafe7bad11d22d2: Bug 1592992 - Part 1: Remove unused jsutil functions. r=jonco
André Bargull <andre.bargull@gmail.com> - Fri, 08 Nov 2019 11:02:20 +0000 - rev 501253
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1592992 - Part 1: Remove unused jsutil functions. r=jonco AddContainerToHash and ForEach aren't used (anymore). Differential Revision: https://phabricator.services.mozilla.com/D51360
bec112cfa8d2c34fc5ccc1d87a9d14f22884ee7d: Bug 1593975 - update test. r=jonco
Yoshi Cheng-Hao Huang <allstars.chh@gmail.com> - Thu, 07 Nov 2019 14:25:35 +0000 - rev 501096
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1593975 - update test. r=jonco check if enqueueMark is defined in opt build. Differential Revision: https://phabricator.services.mozilla.com/D51994
9d6c5b6e3275e5f28fbe8efc3a8041c849eac2d6: Bug 1593975 - update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco
Yoshi Cheng-Hao Huang <allstars.chh@gmail.com> - Tue, 05 Nov 2019 21:09:48 +0000 - rev 501095
Push 114168 by dluca@mozilla.com at Sun, 10 Nov 2019 03:08:55 +0000
Bug 1593975 - update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51810
6922ef47c25721aa5e7bc2a7bed57161a8b0f21e: Bug 1593975 - update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco
Yoshi Cheng-Hao Huang <allstars.chh@gmail.com> - Tue, 05 Nov 2019 17:32:34 +0000 - rev 500717
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1593975 - update linearWeakMarkingDisabled_ to MainThreadOrGCTaskData. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51810
8834ca679ef71dfa07a0b6842c07d895027c1893: Bug 1587638: Add atom map to XDRIncrementalEncoder and atom table to XDRDecoder r=jonco,tcampbell
Iain Ireland <iireland@mozilla.com> - Thu, 31 Oct 2019 21:57:56 +0000 - rev 500397
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1587638: Add atom map to XDRIncrementalEncoder and atom table to XDRDecoder r=jonco,tcampbell The code that uses these fields is part of a subsequent patch. This patch is just getting the tracing right. Differential Revision: https://phabricator.services.mozilla.com/D48782
3a9b6b73cab7bb07ceea6a599911c668f3b735dc: Bug 1531716 - Part 4: Replace jstypes macros with constexpr functions. r=jonco
André Bargull <andre.bargull@gmail.com> - Mon, 04 Nov 2019 14:04:35 +0000 - rev 500384
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1531716 - Part 4: Replace jstypes macros with constexpr functions. r=jonco JS_BIT and JS_BITMASK are only used in contexts where uint32_t is used, so these two functions are now typed to accept and return uint32_t. JS_HOWMANY and the three JS_ROUND functions are only used with size_t inputs, so these four functions are now typed to accept and return size_t. Differential Revision: https://phabricator.services.mozilla.com/D51142
93e5393aa92b81452cdb11066587e3298aace039: Bug 1531716 - Part 3: Replace ROUNDUP with JS_ROUNDUP. r=jonco
André Bargull <andre.bargull@gmail.com> - Mon, 04 Nov 2019 14:02:57 +0000 - rev 500383
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1531716 - Part 3: Replace ROUNDUP with JS_ROUNDUP. r=jonco Both macros compute the same result, so we can replace ROUNDUP with JS_ROUNDUP. Differential Revision: https://phabricator.services.mozilla.com/D51141
865b84a23e9e349a5556a8a296ddcab73431d761: Bug 1531716 - Part 2: Remove unused macro in vm/Probes.cpp. r=jonco
André Bargull <andre.bargull@gmail.com> - Mon, 04 Nov 2019 14:02:37 +0000 - rev 500382
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1531716 - Part 2: Remove unused macro in vm/Probes.cpp. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51140
0e0afb29911a5a373119caf27b5b65d70a04a731: Bug 1531716 - Part 1: Remove macros for generating the SmallChars array. r=jonco
André Bargull <andre.bargull@gmail.com> - Mon, 04 Nov 2019 14:02:14 +0000 - rev 500381
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1531716 - Part 1: Remove macros for generating the SmallChars array. r=jonco And the two macros to convert to and from SmallChars. Differential Revision: https://phabricator.services.mozilla.com/D51139
e3b05f8385fa1ffdf1924ed51236eb306df15986: Bug 1591342: When setting breakpoints, require usable cross-compartment wrappers. r=jonco
Jim Blandy <jimb@mozilla.com> - Sat, 02 Nov 2019 02:05:01 +0000 - rev 500250
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1591342: When setting breakpoints, require usable cross-compartment wrappers. r=jonco When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the BreakpointSite and Breakpoint objects belong to the code's compartment (logically, at least - they're C++ objects and don't actually have any compartment). Since a `Debugger` and its debuggees must be in separate compartments, the Breakpoint's references to its owning `Debugger` and its handler object must go through cross-compartment wrappers. If we have nuked the `Debugger`'s compartment, it's not clear how we're still trying to set breakpoints in its debuggees, but we should at least throw an error, to capture a JavaScript stack when it occurs. Differential Revision: https://phabricator.services.mozilla.com/D51210
8fcd8060719eaa0db75037e2f0c21e29f3768965: Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco
Steve Fink <sfink@mozilla.com> - Thu, 31 Oct 2019 21:58:44 +0000 - rev 500076
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D50689
f42214158987b271acc419ddd399018623da6b6a: Bug 1591342: When setting breakpoints, require usable cross-compartment wrappers. r=jonco
Jim Blandy <jimb@mozilla.com> - Thu, 31 Oct 2019 14:53:45 +0000 - rev 500064
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1591342: When setting breakpoints, require usable cross-compartment wrappers. r=jonco When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the BreakpointSite and Breakpoint objects belong to the code's compartment (logically, at least - they're C++ objects and don't actually have any compartment). Since a `Debugger` and its debuggees must be in separate compartments, the Breakpoint's references to its owning `Debugger` and its handler object must go through cross-compartment wrappers. If we have nuked the `Debugger`'s compartment, it's not clear how we're still trying to set breakpoints in its debuggees, but we should at least throw an error, to capture a JavaScript stack when it occurs. Differential Revision: https://phabricator.services.mozilla.com/D51210
2c09452b60636f9c49abd321a69cc5efdc2f2b97: Bug 1585536: Track estimated malloc memory use for ICU objects. r=jonco
André Bargull <andre.bargull@gmail.com> - Thu, 31 Oct 2019 16:35:52 +0000 - rev 500051
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1585536: Track estimated malloc memory use for ICU objects. r=jonco The estimated memory is based on the maximum observed memory usage when running the Java script attached to the bug report. Differential Revision: https://phabricator.services.mozilla.com/D51087
6a9b59646d094cb8d8561e15c1f81269651544e9: Bug 1585536: Track estimated malloc memory use for ICU objects. r=jonco
André Bargull <andre.bargull@gmail.com> - Thu, 31 Oct 2019 12:31:04 +0000 - rev 500006
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1585536: Track estimated malloc memory use for ICU objects. r=jonco The estimated memory is based on the maximum observed memory usage when running the Java script attached to the bug report. Differential Revision: https://phabricator.services.mozilla.com/D51087
0b9a68f46ef5444f23416997f78e8ce9195dfcb2: Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 30 Oct 2019 17:33:24 +0000 - rev 499823
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D50689
730504cec75c0c3a54dc9cd2e42ce3a2274d4d31: Bug 1580888 - Stop holding onto mark stack memory between GCs r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 30 Oct 2019 17:32:40 +0000 - rev 499816
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1580888 - Stop holding onto mark stack memory between GCs r=jonco Differential Revision: https://phabricator.services.mozilla.com/D50690
e1838571c234053a0fb1fe48f6f8c043ee5b9f24: Bug 1592487 - update 'delayedMarkingWorkAdded' and 'markLaterArenas' to MainThreadOrGCTaskData. r=jonco
Yoshi Cheng-Hao Huang <allstars.chh@gmail.com> - Wed, 30 Oct 2019 14:51:03 +0000 - rev 499800
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1592487 - update 'delayedMarkingWorkAdded' and 'markLaterArenas' to MainThreadOrGCTaskData. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D51091
1589fa5ffccb2b03fa15baba78db3901808c9105: Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 30 Oct 2019 16:42:33 +0000 - rev 499799
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1580888 - Split mark stack into main stack and spare stack. r=jonco Differential Revision: https://phabricator.services.mozilla.com/D50689
b4a752751ba02d599464ac6a7034403676a14fac: Bug 1580888 - Stop holding onto mark stack memory between GCs r=jonco
Steve Fink <sfink@mozilla.com> - Wed, 30 Oct 2019 16:41:09 +0000 - rev 499798
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1580888 - Stop holding onto mark stack memory between GCs r=jonco Differential Revision: https://phabricator.services.mozilla.com/D50690
d8a841c1c74b2b1fe47c22b4e5b52d22665b6147: Bug 1591889 - bail out early if task is already joined. r=jonco
Yoshi Cheng-Hao Huang <allstars.chh@gmail.com> - Wed, 30 Oct 2019 10:39:10 +0000 - rev 499767
Push 114163 by aiakab@mozilla.com at Thu, 31 Oct 2019 10:03:38 +0000
Bug 1591889 - bail out early if task is already joined. r=jonco GCRuntime::joinTask will call recordParallelPhase(), and causes the parallel duration is multiplied when we call joinTask(sweepMarkTask) multiple times. Differential Revision: https://phabricator.services.mozilla.com/D50933
6dcd901da6317e7b924187acc6d1a6a7d8de2546: Bug 1584538 - Allow debug environment proxy to access aliased module variables after the module script executes, r=jonco.
Brian Hackett <bhackett1024@gmail.com> - Mon, 28 Oct 2019 10:44:15 +0000 - rev 499427
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1584538 - Allow debug environment proxy to access aliased module variables after the module script executes, r=jonco. Differential Revision: https://phabricator.services.mozilla.com/D50747
e4f991bcd89855e7d039ff657056f7f55cb42cb1: Bug 1590845 - Add JS::MemoryUse::Embedding1 through 5. r=tcampbell,jonco
Philip Chimento <philip.chimento@gmail.com> - Thu, 24 Oct 2019 16:50:59 +0000 - rev 499137
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1590845 - Add JS::MemoryUse::Embedding1 through 5. r=tcampbell,jonco This makes JS::AddAssociatedMemory() and JS::RemoveAssociatedMemory() more useful for embedders. Differential Revision: https://phabricator.services.mozilla.com/D50347
843d64235cfa4c3e531159be197219dfe76dae7d: Bug 1586452: Let JSScripts and wasm::Instances own their BreakpointSites and Breakpoints. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:50:02 +0000 - rev 498759
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: Let JSScripts and wasm::Instances own their BreakpointSites and Breakpoints. r=jonco Prior to this patch, the code marked a Debugger if any of its debuggee globals were marked, and it had breakpoints set in JSScripts/Instances that were marked. It cleaned up breakpoints by scanning all JSScripts and wasm::Instances in the zones being collected, looking for breakpoints set in them, and deleting them if either the JSScript/Instance or the owning Debugger was about to be finalized. That byzantine approach is equivalent to having owning edges from JSScripts/Instances to the breakpoints set in them, and from those breakpoints to the Debuggers they belong to. Proof: if a script is live, then its global must be live. If the script has a breakpoint set in it, and its global is live, then its Debugger will be marked, and hence neither the Debugger nor the script will be finalized, and hence the breakpoints will be retained. That second approach handles the situation with a much more traditional tracing process, wherein tracing a script traces its breakpoints, which traces their owning Debuggers. We can simply use cross-compartment wrappers for the edges from the breakpoints to their handlers and Debuggers, which removes a bunch of special cases for the GC to worry about. This patch changes things to use the second approach. - js::DebugScript and js::wasm::DebugState get `trace` and `finalize`/`delete_` methods, which get called from the right places. DebugScript and DebugState become the owners of their `BreakpointSite`s. - `BreakpointSite`s get `trace` and `finalize` methods that visit their `Breakpoint`s. `JSBreakpointSite`s also trace their scripts, and `WasmBreakpointSite`s trace their wasm::Instances. - `Breakpoint`s get a `trace` method that traces their owning `Debugger` and their handler object. They hold these as cross-compartment references, since the `Breakpoint` logically belongs to its code's compartment. Code that uses these fields wraps/unwraps as appropriate. - All the specialized breakpoint sweeping code is deleted: - `Zone::sweepBreakpoints` and its supporting `DebugAPI` functions are deleted. - `Debugger::hasAnyLiveHooks` no longer considers breakpoints. - `DebugAPI::markIteratively` no longer searches for breakpoints to mark. - `DebugAPI::traceAllForMovingGC` no longer traverses breakpoints. Differential Revision: https://phabricator.services.mozilla.com/D49858
dca8e34d8b272526f84887c971036780b1ad2c19: Bug 1586452: Separate removal and destruction of Breakpoints into two methods. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:49:55 +0000 - rev 498758
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: Separate removal and destruction of Breakpoints into two methods. r=jonco Separate `Breakpoint::destroy` into two functions, `Breakpoint::remove`, which takes care of cleaning up empty sites, and `Breakpoint::delete_`, which only removes the breakpoint from its linked lists and frees its storage. Call `Breakpoint::remove` from sites that passed `True` for `destroy`'s `mayDestroySite` argument, and `Breakpoint::delete_` for those that passed `False`. The prior code had a `Breakpoint::destroy` method that took a `mayDestroySite` flag, which indicated whether the BreakpointSite should also be cleaned up, if the outgoing breakpoint was the last one left. Given that we never intend to leave empty BreakpointSites lying around, it was unclear why this option was needed. And indeed, it was passed as `True` (yes, please destroy the site if empty) from all call sites except one, in `js::wasm::DebugState::clearBreakpointsIn`. This function is used for both deleting individual breakpoints and removing all breakpoints set in a particular `wasm::Instance`, so it has two nested loops, the outer visiting all sites in the instance, and the inner visiting each site's breakpoints. Since `DebugState` stores `WasmBreakpointSites` in a hash table, allowing `Breakpoint::destroy` to remove empty `BreakpointSite`s would invalidate the outer loop's iteration, a classic bug. Instead, the inner loop forbade `Breakpoint::destroy` from removing the site, and cleaned it up itself, if empty, at the bottom of the outer loop body. Later patches in this series want a cleaner separation between the high-level operation of removing a single breakpoint, with whatever followup that entails, versus the low-level of operation of simply freeing the structure at hand. Differential Revision: https://phabricator.services.mozilla.com/D49857
df4696b00c376826a45b750bcb37c9cbdf0fdcd5: Bug 1586452: SetBreakpointMatcher: success path should be main line. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:49:43 +0000 - rev 498757
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: SetBreakpointMatcher: success path should be main line. r=jonco No effect on behavior. It's SpiderMonkey's convention that the success path should be the top-level path through a function, and that failure should be handled by early returns. This patch makes SetBreakpointMatcher's methods conform to that convention. Differential Revision: https://phabricator.services.mozilla.com/D49856
b49320ce9db53381350d9ed548d951b9d6db2a7c: Bug 1586452: Manage JIT traps when we create and remove breakpoint sites. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:49:35 +0000 - rev 498756
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: Manage JIT traps when we create and remove breakpoint sites. r=jonco `Debugger` objects used to have an `enabled` property, which controlled (among other things) whether breakpoints would fire. This meant that it was possible to have a BreakpointSite that had breakpoints set in it, but yet should never trigger. Thus, whether or not the JIT code itself should be patched for the breakpoint depended on both 1) whether breakpoints were set, and 2) whether any of those breakpoints' owning Debuggers were enabled. To manage this, each BreakpointSite had not only a linked list of inserted breakpoints, but an 'enabled count' of how many of those breakpoints were in enabled Debuggers. Enabling/disabling a Debugger walked all its breakpoints and adjusted their sites' counts. When the enabled count was non-zero, the JIT code needed traps inserted; when it was zero, the trap sites could be filled with no-ops. The `enabled` property seemed like an innocent idea, but it turns out to have introduced all sorts of hair like this throughout the Debugger (for example, also making it harder for the GC to figure out what could be removed without observable effect), and then it turned out that the server never really wanted to toggle them on and off anyway. So we removed 'enabled' in bug 1564168. But this means that a BreakpointSite's enabled count should be non-zero if and only if its breakpoint list is non-empty; the count is redundant and can be removed. Further, since an empty BreakpointSite should be removed altogether, any inserted BreakpointSite can be assumed to have a non-zero enabled count. In other words, JIT code should have traps inserted if and only if a BreakpointSite is present for that code location. This means we can tie JIT code trap insertion and removal to BreakpointSite insertion and removal. Since BreakpointSite is an abstract base class, all the code that inserts and removes sites knows which concrete class it's creating, so we know statically how to go about patching the code. This means BreakpointSite no longer needs a 'recompile' pure virtual method. Its implementations get merged into the code that's inserting and removing BreakpointSite concrete instances. Differential Revision: https://phabricator.services.mozilla.com/D49855
7fc4169017bc5c1a0a97559e6f6382c25c32c6bb: Bug 1586452: Make `js::BreakpointSite::remove` the pure virtual method, and hoist `removeIfEmpty' into the base class. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:49:28 +0000 - rev 498755
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: Make `js::BreakpointSite::remove` the pure virtual method, and hoist `removeIfEmpty' into the base class. r=jonco The way a breakpoint site is removed depends on the concrete subclass, but deciding whether the site is empty or not is common to all BreakpointSites. There's no reason to repeat the condition in every implementation. Differential Revision: https://phabricator.services.mozilla.com/D49854
4d3fe0b933978a05af738c8a8729fe1877cd0db2: Bug 1586452: Remove class js::WasmBreakpoint; use plain js::Breakpoint instead. r=jonco
Jim Blandy <jimb@mozilla.com> - Wed, 23 Oct 2019 19:49:21 +0000 - rev 498754
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1586452: Remove class js::WasmBreakpoint; use plain js::Breakpoint instead. r=jonco All the information we need specific to Wasm breakpoints is available in the WasmBreakpointSite now, so there's no need for two different kinds of breakpoints any more. Code that used to obtain the wasm instance from the breakpoint now consults the site instead. BreakpointSite::allocSize confusingly provided the size of the site's *breakpoints*, not the site itself; but now it's no longer needed at all, and can be removed. Differential Revision: https://phabricator.services.mozilla.com/D49853