a7f12e31f7e02368b00d72ac73bf3c661d55d0ad: Backed out changeset 1536fa69bad4 (bug 1399758) for Hazard failures. r=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Fri, 15 Sep 2017 10:00:52 +0200 - rev 665566
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Backed out changeset 1536fa69bad4 (bug 1399758) for Hazard failures. r=backout
50770364778192f030136c3ac91528fbe994df28: Bug 1399921 - Register zone allocator independently, and delay jemalloc initialization on mac. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 07:34:48 +0900 - rev 665565
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1399921 - Register zone allocator independently, and delay jemalloc initialization on mac. r=njn In bug 1361258, we unified the initialization sequence on mac, and chose to make the zone registration happen after jemalloc initialization. The order between jemalloc init and zone registration shouldn't actually matter, because jemalloc initializes the first time the allocator is actually used. On the other hand, in some build setups (e.g. with light optimization), the initialization of the thread_arena thread local variable can happen after the forced jemalloc initialization because of the order the corresponding static initializers run. In some levels of optimization, the thread_arena initializer resets the value the jemalloc initialization has set, which subsequently makes choose_arena() return a bogus value (or hit an assertion in ThreadLocal.h on debug builds). So instead of initializing jemalloc from a static initializer, which then registers the zone, we instead register the zone and let jemalloc initialize itself when used, which increases the chances of the thread_arena initializer running first.
013516394a9cd0ccfed501b78f796cfdf877654d: Bug 1400146 - Gracefully handle the allocator not being initialized in isalloc_validate. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 15:13:52 +0900 - rev 665564
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1400146 - Gracefully handle the allocator not being initialized in isalloc_validate. r=njn isalloc_validate is the function behind malloc_usable_size. If for some reason malloc_usable_size is called before mozjemalloc is initialized, this can lead to an unexpected crash. The chance of this actually happening is rather slim on Linux and Windows (although still possible), and impossible on Mac, due to the fact the earlier something can end up calling it is after the mozjemalloc zone is registered, which happens after initialization. ... except with bug 1399921, which reorders that initialization, and puts the zone registration first. There's then a slim chance for the zone allocator to call into zone_size, which calls malloc_usable_size, to determine whether a pointer allocated by some other zone belongs to mozjemalloc's. And it turns out that does happen, during the startup of the plugin-container process on OSX 10.10 (but not more recent versions).
7f7d9a165b2fd988d4c8153352e0301dc9f364c5: Bug 1399382 - Add a pref to hide credit card autofill feature, r=lchang
Scott Wu <scottcwwu@gmail.com> - Wed, 13 Sep 2017 18:50:39 +0800 - rev 665563
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1399382 - Add a pref to hide credit card autofill feature, r=lchang MozReview-Commit-ID: 2GIOrLBmFKR
738de4c495b950a459772024a74ba9bc32d0c68f: Bug 1400096 - Don't define the operator new/delete functions as mangled in mozmem_wrap.cpp. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 10:28:33 +0900 - rev 665562
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1400096 - Don't define the operator new/delete functions as mangled in mozmem_wrap.cpp. r=njn Now that this is a C++ file, and that the function names are not mangled, we can just use the actual C++ names. We do however need to replace MOZ_MEMORY_API, which implies extern "C", with MFBT_API. Also use the correct type for the size given to operator new. It happened to work before because the generated code would just jump to malloc without touching any register, but on aarch64, unsigned int was the wrong type.
09aa9fae62808374cf8d78e01a8e7ac8c428b3d2: Bug 1400096 - Build mozmemory_wrap as C++. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 10:19:37 +0900 - rev 665561
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1400096 - Build mozmemory_wrap as C++. r=njn And since the build system doesn't handle transitions from foo.c to foo.cpp properly without a clobber, we work around the issue by switching to unified sources.
092857175e36c1c9c0d8d74436f432dc57deba11: Bug 1400096 - Annotate mozmemory_wrap.c windows functions as MOZ_MEMORY_API. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 10:12:24 +0900 - rev 665560
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1400096 - Annotate mozmemory_wrap.c windows functions as MOZ_MEMORY_API. r=njn It happens to work because of mozglue.def, but we might as well have the right annotations (which will also make things correct when building this file to C++)
6cf651d919d1aa049d0b88c1ca8f91c0c33ee56b: Bug 1400096 - Remove mozmem_malloc_impl wrapping for operator methods exposed in mozmemory_wrap.c. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Fri, 15 Sep 2017 09:54:01 +0900 - rev 665559
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1400096 - Remove mozmem_malloc_impl wrapping for operator methods exposed in mozmemory_wrap.c. r=njn This used to be necessary because those functions might be prefixed with __wrap_, and linked against with -Wl,--wrap, but that's not been the case since bug 1077366. Furthermore, mozmem_malloc_impl nowadays only does something on Windows, and those operators are only exposed on Android.
ba8d3ecc2412f0025e715a8ecd9a527ca44ef5e0: Bug 1397307 - P10. Remove uncessary loop. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 14 Sep 2017 14:45:10 +0200 - rev 665558
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P10. Remove uncessary loop. r=gerald We only process a demuxed sample at a time. Waiting until one is decoded to do the next pending ones. MozReview-Commit-ID: JlXhyPzso8U
7558fb4b16997621dab4b82e3dd0a5d81e0c4488: Bug 1397307 - P9. Pass video frame rate to RemoteVideoDecoder and GPU process. r=mattwoodrow
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 18:29:40 +0200 - rev 665557
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P9. Pass video frame rate to RemoteVideoDecoder and GPU process. r=mattwoodrow MozReview-Commit-ID: BDSO332f3B6
0cf29b887325d88990f8c6b3ff77ba28e416424a: Bug 1397307 - P8. Pass averaged video frame rate to constructor. r=mattwoodrow
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 17:55:03 +0200 - rev 665556
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P8. Pass averaged video frame rate to constructor. r=mattwoodrow MozReview-Commit-ID: FMFz3RdFsHA
1df89fb6ff5d24981157557a82de345b6da3f100: Bug 1397307 - P7. Display video resolution and frame rate in debug data. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 17:40:42 +0200 - rev 665555
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P7. Display video resolution and frame rate in debug data. r=gerald MozReview-Commit-ID: 9vsheKkAm4p
3fbbe2c4ec7be1057bbca4eab35bfbb4bad8de9c: Bug 1397307 - P6. Calculate average video frame rate as video is playing. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 21:20:09 +0200 - rev 665554
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P6. Calculate average video frame rate as video is playing. r=gerald We unfortunately can't store this information in the VideoInfo as typically the framerate isn't found in the container's metadata. Additionally, the VideoInfo object is readable-only as it is shared across threads. As such, we can only estimate it as we demux samples. MozReview-Commit-ID: 5HB33ubfGAs
768bf2920dab786813f9a698bd5c5b1778f09508: Bug 1397307 - P5. Avoid creating two decoders on first sample. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 21:02:24 +0200 - rev 665553
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P5. Avoid creating two decoders on first sample. r=gerald Don't unnecessarily, create a decoder, flush, shutdown and create a new one on the first sample. MozReview-Commit-ID: 8utEX5JEmq8
3fa8d29b3026c85ee6b0e956e2db1a490d0aefc7: Bug 1397307 - P4. Fix style. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 12 Sep 2017 11:09:15 +0200 - rev 665552
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P4. Fix style. r=gerald MozReview-Commit-ID: 1Q3kwsDlAhI
9d597b2bcf3518432ec8325b07b0a8b85b1666ca: Bug 1397307 - P3. Remove unused method. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Mon, 11 Sep 2017 17:37:44 +0200 - rev 665551
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P3. Remove unused method. r=gerald Code was incorrect anyway. MozReview-Commit-ID: Bf0O4Mhu1P6
70899b90b6fe4a1be0650318a14ad40bcb604948: Bug 1397307 - P2. Wrap boolean in structure to prevent unwanted conversion. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Fri, 08 Sep 2017 15:45:38 +0200 - rev 665550
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P2. Wrap boolean in structure to prevent unwanted conversion. r=gerald Automatic conversion (say from int to bool) makes DecoderParam difficult to extend. MozReview-Commit-ID: G0T7jPogskN
c60b5da550ea3b664a9a81fb5dd9708bf7491657: Bug 1397307 - P1. Make method const. r=gerald
Jean-Yves Avenard <jyavenard@mozilla.com> - Fri, 08 Sep 2017 12:49:01 +0200 - rev 665549
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1397307 - P1. Make method const. r=gerald MozReview-Commit-ID: 2UrTZroXpRG
1536fa69bad4d6ee7f1f4c265fab57504f6263d9: Bug 1399758 - Measure ImageValue objects. r=heycam.
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 14 Sep 2017 18:48:19 +1000 - rev 665548
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
Bug 1399758 - Measure ImageValue objects. r=heycam. We have about 11,500 of these when loading gmail in a Stylo-enabled build, from SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and the strings within them about 2.9 MiB. We also have a very small number of them on the Gecko side. MozReview-Commit-ID: AduCIaDIzGG
e2f8c9f76b711c89b04ca0e2f2ac324e638ac704: servo: Merge #18515 - Measure ImageValue objects (from nnethercote:bug-1399758); r=heycam
Nicholas Nethercote <nnethercote@mozilla.com> - Thu, 14 Sep 2017 22:06:43 -0500 - rev 665547
Push 80115 by bmo:eoger@fastmail.com at Fri, 15 Sep 2017 18:29:01 +0000
servo: Merge #18515 - Measure ImageValue objects (from nnethercote:bug-1399758); r=heycam We have about 11,500 of these when loading gmail in a Stylo-enabled build, from SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and the strings within them about 2.9 MiB. We also have a very small number of them on the Gecko side. <!-- Please describe your changes on the following line: --> --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [ ] These changes fix #__ (github issue number if applicable). <!-- Either: --> - [ ] There are tests for these changes OR - [X] These changes do not require tests because tested on Gecko side. <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. --> Source-Repo: https://github.com/servo/servo Source-Revision: db689094f1413f542961cbe0d19a3ed82a11f682
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip