0c48370413925b4b13ea87c0f65cfc56b88e8ce7: Bug 1550108 - Reduce stack size on StartupCache threads r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:45:41 +0000 - rev 496408
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Reduce stack size on StartupCache threads r=froydnj Differential Revision: https://phabricator.services.mozilla.com/D46225
36a2b9138e114d0da2bce5a237a0200c1c9a0eb0: Bug 1550108 - Prefetch StartupCache off main thread r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:45:32 +0000 - rev 496407
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Prefetch StartupCache off main thread r=froydnj Does what it says on the tin. Once we have a central scheduling system this should likely just consume that. Differential Revision: https://phabricator.services.mozilla.com/D35454
c90c4ca6cd25703422c14481dd29f5b0b7885f37: Bug 1550108 - Compact the StartupCache if it is bloated r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:45:18 +0000 - rev 496406
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Compact the StartupCache if it is bloated r=froydnj The first run loads more things into the StartupCache than are used on the second and subsequent runs. This just ensures that if the StartupCache diverges too far from its actual use that we will rebuild it. Differential Revision: https://phabricator.services.mozilla.com/D34654
849df6250b7e0fe49d4f32c993b241114b357687: Bug 1550108 - Eliminate large buffer copies from StartupCache r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:45:09 +0000 - rev 496405
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Eliminate large buffer copies from StartupCache r=froydnj The signatures were updated in the previous patch to hand us the raw, uncopied buffers. This just adjusts the callsites to match. Differential Revision: https://phabricator.services.mozilla.com/D34653
992e2a6359f950a35bb9f01f77e6e6c8f7ed6740: Bug 1550108 - Change StartupCache format from zip to custom r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:59 +0000 - rev 496404
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Change StartupCache format from zip to custom r=froydnj I am not aware of anything that depends on StartupCache being a zip file, and since I want to use lz4 compression because inflate is showing up quite a lot in profiles, it's simplest to just use a custom format. This loosely mimicks the ScriptPreloader code, with a few diversions: - Obviously the contents of the cache are compressed. I used lz4 for this as I hit the same file size as deflate at a compression level of 1, which is what the StartupCache was using previously, while decompressing an order of magnitude faster. Seemed like the most conservative change to make. I think it's worth investigating what the impact of slower algs with higher ratios would be, but for right now I settled on this. We'd probably want to look at zstd next. - I use streaming compression for this via lz4frame. This is not strictly necessary, but has the benefit of not requiring as much memory for large buffers, as well as giving us a built-in checksum, rather than relying on the much slower CRC that we were doing with the zip-based approach. - I coded the serialization of the headers inline, since I had to jump back to add the offset and compressed size, which would make the nice Code(...) method for the ScriptPreloader stuff rather more complex. Open to cleaner solutions, but moving it out just felt like extra hoops for the reader to jump through to understand without the benefit of being more concise. Differential Revision: https://phabricator.services.mozilla.com/D34652
8cb90c97dddbe98e8071e72e60fa0d58f4a486d6: Bug 1550108 - Add mapErr method to Result r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:50 +0000 - rev 496403
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Add mapErr method to Result r=froydnj Adds an explicit error mapping function to Result, to simplify using MOZ_TRY... macros. Differential Revision: https://phabricator.services.mozilla.com/D47466
fbba9fe4330385dfca0c9065935eb70a9641b5fb: Bug 1550108 - Split out Input/OutputBuffer into their own file r=froydnj
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:41 +0000 - rev 496402
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Split out Input/OutputBuffer into their own file r=froydnj This just splits out the InputBuffer and OutputBuffer helper classes to make it cleaner for the StartupCache to include them. Differential Revision: https://phabricator.services.mozilla.com/D34651
7915439e3c10e850b57bc775f556ac383371af5c: Bug 1550108 - Avoid decompressing entries just to check if they exist r=kmag
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:32 +0000 - rev 496401
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Avoid decompressing entries just to check if they exist r=kmag This will not behave exactly the same if we had previously written bad data for the entry that would fail to decompress. I imagine this is rare enough, and the consequences are not severe enough, that this should be fine. Differential Revision: https://phabricator.services.mozilla.com/D30643
eb37df99073404d94558daaff283bd4e96583d69: Bug 1550108 - Don't read from app/gre caches in StartupCache r=kmag
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:18 +0000 - rev 496400
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Don't read from app/gre caches in StartupCache r=kmag I thought I had already written out the patch to remove these, but apparently not. Per discussion in the startup cache telemetry bug, there should be no reason for doing this. Differential Revision: https://phabricator.services.mozilla.com/D31491
ea19d193ebbbe579e517e7da0d26b6390eb011e2: Bug 1550108 - Pull in secondary lz4 libraries r=glandium
Doug Thayer <dothayer@mozilla.com> - Fri, 04 Oct 2019 20:44:08 +0000 - rev 496399
Push 97222 by dothayer@mozilla.com at Fri, 04 Oct 2019 20:50:04 +0000
Bug 1550108 - Pull in secondary lz4 libraries r=glandium I opted to go with what I perceived as the more expedient route of leaving lz4 roughly where it is and just adding to that. The biggest complication was xxhash, which is included elsewhere. I'm not generally proficient with build-related things though so my solution may be wrong and not just ugly. Differential Revision: https://phabricator.services.mozilla.com/D30640
ea0524a93cf3d94bf808c41ce879d14cdd12e04e: Bug 1584195: Break Debugger.Frame -> generator JSScript edges before finalization. r=jonco
Jim Blandy <jimb@mozilla.com> - Thu, 03 Oct 2019 17:46:52 +0000 - rev 496398
Push 97221 by jblandy@mozilla.com at Fri, 04 Oct 2019 20:47:41 +0000
Bug 1584195: Break Debugger.Frame -> generator JSScript edges before finalization. r=jonco When a Debugger.Frame refers to a generator or async function call, the script must be compiled with instrumentation to notify the Debugger API when the call is resumed. To accomplish this, a generator's JSScript's DebugScript's generatorObserverCount tracks the number of Debugger.Frames referring to calls running the script. When the count is non-zero, instrumentation is required. When a Debugger.Frame for a suspended generator call is garbage collected, its JSScript's generatorObserverCount must be decremented. However, if the JSScript is alo being garbage collected, it may have already been finalized, and should not be touched. The prior code had js::DebuggerFrame::finalize use IsAboutToBeFinalized to check whether the JSScript was healthy enough to have its count decremented. Since the garbage collector always handles debuggers and debuggees in the same GC cycle, it was believed that the JSScript's mark bit (what IsAboutToBeFinalized checks) would be accurate. Unfortunately, it is possible for a JSScript to be finalized in one GC slice, and then for the mutator to run, and then for the DebuggerFrame to be finalized in the next slice, with the JSScript's arena available for new allocations in the middle. When an arena is made available for allocation during an incremental GC, all its mark bits are set. As a result, the DebuggerFrame finalizer believes that the JSScript it was referring to is still alive, even thought it has been finalized. IsAboutToBeFinalized is only safe to use on edges between cells of the same alloc kind, since we do promise to run all finalizers for a given alloc kind before putting those arenas up for reuse. It's not safe to use IsAboutToBeFinalized to inspect edges between cells of differing alloc kinds, like DebuggerFrame JSObjects and generator JSScripts. Fortunately, there is another approach we can take. The garbage collector calls `DebugAPI::sweepAll` after all marking is done, but before any finalization takes place. At this point, all cells' mark bits are accurate (assuming they're in a zone being GC'd), but nothing has been finalized. We can disconnect unmarked DebuggerFrames from their scripts now, knowing that both parties are still fully initialized. Differential Revision: https://phabricator.services.mozilla.com/D47721
8c47c7026dac9810f8d9f16e0c3ead1e3baeb5c6: Bug 1586336, Replace XUL textbox with HTML input in testcases within layout directory r=dholbert
Emma Malysz <emalysz@mozilla.com> - Fri, 04 Oct 2019 19:45:56 +0000 - rev 496397
Push 97220 by bgrinstead@mozilla.com at Fri, 04 Oct 2019 20:45:52 +0000
Bug 1586336, Replace XUL textbox with HTML input in testcases within layout directory r=dholbert Differential Revision: https://phabricator.services.mozilla.com/D48126
b15c0747d702c0f883099ec1a7e1b5402f621fc5: Bug 1583244 - Provide unfuzzed timings for UserTiming markers. r=gregtatum
Jason Laster <jlaster@mozilla.com> - Fri, 04 Oct 2019 18:51:45 +0000 - rev 496396
Push 97219 by jlaster@mozilla.com at Fri, 04 Oct 2019 20:05:22 +0000
Bug 1583244 - Provide unfuzzed timings for UserTiming markers. r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D48092
23839eda99ddf769769fefe89a12bb35ede464fb: Bug 158968 - Implement kiosk mode. r=Gijs
Michael Kaply <mozilla@kaply.com> - Fri, 04 Oct 2019 19:47:56 +0000 - rev 496395
Push 97218 by mozilla@kaply.com at Fri, 04 Oct 2019 19:58:37 +0000
Bug 158968 - Implement kiosk mode. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D41848
e4085fae0f8b77dcfdec85d52d518624f8b6593d: Bug 1585702 - [lint] Remove temporary hacks now that 'null character' issue is fixed, r=gbrown
Andrew Halberstadt <ahalberstadt@mozilla.com> - Fri, 04 Oct 2019 19:13:04 +0000 - rev 496394
Push 97217 by ahalberstadt@mozilla.com at Fri, 04 Oct 2019 19:41:48 +0000
Bug 1585702 - [lint] Remove temporary hacks now that 'null character' issue is fixed, r=gbrown Depends on D48113 Differential Revision: https://phabricator.services.mozilla.com/D48209
9ea7f7d1768681d657daf36134d7a7d681b2e879: Bug 1585702 - [mozprocess] Fix "Embedded null character" error in Windows with Python 3, r=gbrown
Andrew Halberstadt <ahalberstadt@mozilla.com> - Fri, 04 Oct 2019 17:46:38 +0000 - rev 496393
Push 97217 by ahalberstadt@mozilla.com at Fri, 04 Oct 2019 19:41:48 +0000
Bug 1585702 - [mozprocess] Fix "Embedded null character" error in Windows with Python 3, r=gbrown This works around a bug in Python: https://bugs.python.org/issue32745 Null characters aren't allowed in 'c_wchar_p' types anymore, but we can get around the issue by allocating a buffer in memory and casting it after the fact. This was discovered via trial and error and I'm not really sure why it works.. But it does. This also enables the tests under Python 3 on Windows (which thankfully all seem to pass). Differential Revision: https://phabricator.services.mozilla.com/D48113
9bfffecb5b805b006e8a8e8475af3352cc1cf61b: Bug 1433941 - Passed remainder arguments as it is |mach python-test| r=ahal
Anmol Agarwal <anmol.agarwal001@gmail.com> - Fri, 04 Oct 2019 18:32:37 +0000 - rev 496392
Push 97216 by ahalberstadt@mozilla.com at Fri, 04 Oct 2019 19:41:14 +0000
Bug 1433941 - Passed remainder arguments as it is |mach python-test| r=ahal Differential Revision: https://phabricator.services.mozilla.com/D47832
35dfc96baca17659e3ef42c16c5d85c5adc5fc0e: Bug 1576254 - Add isSystemOrAddonPrincipal to RustJSPrincipal r=luke
Tom Ritter <tom@mozilla.com> - Fri, 04 Oct 2019 17:38:03 +0000 - rev 496391
Push 97215 by tritter@mozilla.com at Fri, 04 Oct 2019 19:40:14 +0000
Bug 1576254 - Add isSystemOrAddonPrincipal to RustJSPrincipal r=luke RustJSPrincipal is used in Servo; we just return the conservative value of 'false'. Differential Revision: https://phabricator.services.mozilla.com/D47478
7c7ccb6e9ce55f60a540d993bb83854b7f735d36: Bug 1576254 - Add isSystemOrAddonPrincipal to JSPrincipal and nsJSPrincipals r=luke
Tom Ritter <tom@mozilla.com> - Fri, 04 Oct 2019 17:37:36 +0000 - rev 496390
Push 97215 by tritter@mozilla.com at Fri, 04 Oct 2019 19:40:14 +0000
Bug 1576254 - Add isSystemOrAddonPrincipal to JSPrincipal and nsJSPrincipals r=luke Finally, here we add the virtual method isSystemOrAddonPrincipal to the JSPrincipal object. We also add it to nsJSPrincipal (where it has an easy implementation), and to carry classes that are used by JS tests and the shell. Differential Revision: https://phabricator.services.mozilla.com/D47477
2498e68e641cbac86bac59a54ffd8372e2a905ec: Bug 1576254 - Cut WorkerPrincipal over to a real object and implement isSystemOrAddonPrincipal r=baku
Tom Ritter <tom@mozilla.com> - Fri, 04 Oct 2019 17:37:09 +0000 - rev 496389
Push 97215 by tritter@mozilla.com at Fri, 04 Oct 2019 19:40:14 +0000
Bug 1576254 - Cut WorkerPrincipal over to a real object and implement isSystemOrAddonPrincipal r=baku Unlike WorkletPrincipal, a WorkerPrincipal had been a simple static object shared by all Workers. We never needed to consult it about an individual Worker before. Now we do. So we cut it over from a static object to individual objects for each Worker. We have an off main thread access problem for the Principal however, WorkerPrivate has a method UsesSystemPrincipal that returns a bool that was initialized from the Principal on the main thread. We copy that pattern and add a UsesAddonOrExpandedAddonPrincipal method that will be called by the isSystemOrAddonPrincipal method we must implement so we can inheirt from JSPrincipal. Differential Revision: https://phabricator.services.mozilla.com/D47476
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip