cc5eaeefd44520822edf91a49355d354d6f38ad5: Bug 1368837 - Replace debugging ReadAt with CachedReadAt code - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Mon, 29 May 2017 13:36:27 +1200 - rev 361723
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - Replace debugging ReadAt with CachedReadAt code - r=cpearce MozReview-Commit-ID: 88j9oAPdI0w
b3dff4b28a95446bdae8c91e15ec1a5b5ab5b6c7: Bug 1368837 - media.cache.resource-index controls the MediaResourceIndex cache size - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 May 2017 21:43:28 +1200 - rev 361722
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - media.cache.resource-index controls the MediaResourceIndex cache size - r=cpearce 8KB by default, otherwise using the next power of two from the given media.cache.resource-index (but staying within 32B-128KB). '0' means we don't want to use caching. MozReview-Commit-ID: 8LmS15Ft2MA
b9d2d284df0d2224049140932cf0e4d9fe2f702d: Bug 1368837 - MediaResourceIndex::ReadAt tries to cache last-read block - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 May 2017 14:59:30 +1200 - rev 361721
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - MediaResourceIndex::ReadAt tries to cache last-read block - r=cpearce This is the core of this bug: - We try to read past the end of the requested range, and save a block-full of cached data. ("Block" is a memory range, with an alignment and size being a power of two, to match existing caching happening in MediaCache and FileBlockCache, and to play nice with the memory allocator.) - If part of a requested read touches the existing cache, we can just read from the cache, which means we don't involve any of the locking and IOs that normal reads use. The small extra work needed to cache more data in some reads is largely offset by all the lock&IO-heavy reads that we can subsequently avoid. UncachedReadAt, which is used internally by CachedReadAt, is left public because it could be useful if the caller knows for sure that a particular read is isolated. (Note: The printfs, and comparison code in ReadAt, will be removed in later patches. Also the block size will be later controlled by a pref.) MozReview-Commit-ID: GFiaP5Io7Hf
9b1ef0d8d9605c49a7a96214107be59d94a227dd: Bug 1368837 - WaveTrackDemuxer should copy the MediaResource* instead of a whole MediaResourceIndex - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 May 2017 21:42:22 +1200 - rev 361720
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - WaveTrackDemuxer should copy the MediaResource* instead of a whole MediaResourceIndex - r=cpearce When the WaveTrackDemuxer is given a MediaResourceIndex, it's only really interested in the MediaResource pointer, so we should just pass that, and WaveTrackDemuxer can construct its own MediaResourceIndex from it. Also, MediaResourceIndex will become non-copyable soon. MozReview-Commit-ID: H0VGSxpAGkP
2f9a486c2dbbfce70a97ea9ae2832ed9fac0f266: Bug 1368837 - MockMediaResource should fread individual bytes - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Fri, 26 May 2017 15:15:14 +1200 - rev 361719
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - MockMediaResource should fread individual bytes - r=cpearce `fread(buf, count, 1, f)` meant that exactly one object of size `count` could be read. Changing that to `fread(buf, 1, count, f)` now reads up to `count` size-1 objects (aka bytes) up to `count` and returns that number of bytes read, which is usually what we want from a read, i.e. as much as possible even if it's less than requested. MozReview-Commit-ID: 3Lgvws19SFd
a341e170f306d01a9ade7eba3158edfe1c50995c: Bug 1368837 - MockMediaResource::GetCachedDataEnd should return the offset if out of range - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Mon, 29 May 2017 15:13:15 +1200 - rev 361718
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - MockMediaResource::GetCachedDataEnd should return the offset if out of range - r=cpearce If the requested cached-data offset is out of range, we should just return the same offset, as it signals that the actual cached range is 0 bytes, without having to deal with -1. MozReview-Commit-ID: D0rXO0S0mss
d7836ae27b65d4e511d3bf047380e1fb83124002: Bug 1368837 - Implement SourceBufferResource::GetCachedDataEnd - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Mon, 29 May 2017 14:51:08 +1200 - rev 361717
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - Implement SourceBufferResource::GetCachedDataEnd - r=cpearce MediaResourceIndex caching requires GetCachedDataEnd and ReadFromCache. Implementing SourceBufferResource::GetCachedDataEnd is trivial, as it's just a buffer from 0 to GetLength(), so if the requested cached-data offset is inside the buffer, we can just return the total length as known cached data. MozReview-Commit-ID: 1DO0PzDnjQp
e38d5530bf2b18ee63a7b3a1f7633376a0ce0969: Bug 1368837 - BufferMediaResource::GetCachedDataEnd should return aOffset when out of cache - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Thu, 01 Jun 2017 11:30:14 +1200 - rev 361716
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - BufferMediaResource::GetCachedDataEnd should return aOffset when out of cache - r=cpearce MozReview-Commit-ID: 6EEXSUxShLp
7a404b72b9b8f89046938755e17c17de333dfdf5: Bug 1368837 - Document that MediaResource::GetCachedDataEnd should return aOffset when out of cache - r=cpearce
Gerald Squelart <gsquelart@mozilla.com> - Thu, 01 Jun 2017 11:29:49 +1200 - rev 361715
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368837 - Document that MediaResource::GetCachedDataEnd should return aOffset when out of cache - r=cpearce MozReview-Commit-ID: JKeuEAjIRxr
d2e141768c617d8e45c89d1f55e1f5659fefc5e3: Bug 1353029 - Pass PdfJs.enabled into child on change r=bdahl
Doug Thayer <dothayer@mozilla.com> - Tue, 30 May 2017 16:34:53 -0700 - rev 361714
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1353029 - Pass PdfJs.enabled into child on change r=bdahl isDefaultHandler in PdfJs.jsm appears to only be called on startup and when the settings for pdfs (either the pref or the setting in about:preferences) are changed. During startup, it's only the parent process which makes this call, which it uses to conditionally load a script in the content process. On change, the parent process controls notifying the content process, so it can simply pass along the enabled boolean. This change simply shifts to pass this boolean along to the child, and adds some guards to assert that we're only checking the actual values in the parent process. MozReview-Commit-ID: 9JSEJqHR2Ni
bc5283bd5f85f9de1c17a2d86c1a0a7eec48dce1: Bug 1368932 - Add a testcase for a replace-malloc library that doesn't implement all functions. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Wed, 31 May 2017 15:04:32 +0900 - rev 361713
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Add a testcase for a replace-malloc library that doesn't implement all functions. r=njn
4bd3eb1b5f3761565871f226e80c4b158defdf48: Bug 1368932 - Handle missing replace_posix_memalign at the replace-malloc level. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Wed, 31 May 2017 13:47:17 +0900 - rev 361712
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Handle missing replace_posix_memalign at the replace-malloc level. r=njn Replace-malloc libraries, such as DMD, don't really need to care about the details of implementing all the variants of aligned memory allocation functions. Currently, by defining MOZ_REPLACE_ONLY_MEMALIGN before including replace_malloc.h, they get predefined functions. Instead of making that an opt-in at build time, we make the replace-malloc initialization just fill the replace-malloc malloc_table_t with implementations that rely on the replace_memalign the library provides.
4753d3677cbe1780928b7b9844700539604c3218: Bug 1368932 - Move the replace_malloc_init_funcs function around. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Wed, 31 May 2017 13:47:11 +0900 - rev 361711
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Move the replace_malloc_init_funcs function around. r=njn
13a1349fb675560c774b9c8157f0e86c37e620e8: Bug 1368932 - Fill the replace-malloc malloc_table_t with the real allocator as a fallback. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Tue, 30 May 2017 15:57:28 +0900 - rev 361710
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Fill the replace-malloc malloc_table_t with the real allocator as a fallback. r=njn Until now, the malloc implementation functions would call the replace-malloc functions if they exist, and fallback to the real allocator in no such function exists. Instead of doing this, we now fill the empty slots in the malloc_table_t with the real allocator functions.
ff2a02c2733bcb2280baf75911861321bb53d810: Bug 1368932 - Use a malloc_table_t for most replace-malloc function pointers, on all platforms. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Tue, 30 May 2017 15:57:28 +0900 - rev 361709
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Use a malloc_table_t for most replace-malloc function pointers, on all platforms. r=njn We make replace_malloc_init_funcs called on all platforms and fill out a malloc_table_t for the replace-malloc functions with what comes from dlsym/GetProcAddress on Android/Windows, and from the dynamically linked weak symbols replace_* on other platforms. replace_malloc.h contains definitions of *_impl_t types for each of the functions in the malloc_table_t, which is redundant with the replace_*_impl_t types we were creating, so we remove those typedefs, except for the two functions (init and get_bridge) that don't have such a typedef. Those functions don't appear in malloc_table_t.
3f71138313da560bddc42152421cb529f4d54e0f: Bug 1368932 - Refactor such that there is only one definition of replace_malloc_init_funcs. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Tue, 30 May 2017 15:57:28 +0900 - rev 361708
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Refactor such that there is only one definition of replace_malloc_init_funcs. r=njn We want, in a subsequent patch, to have replace_malloc_init_funcs be called on all platforms (including those relying on the replace-malloc library being loaded already) and perform more initialization. To prepare for that, we move the non-platform-specific pieces out.
3d78fdcff608b2486ea7b75cb9b5fe31b75cc2ed: Bug 1368932 - Generate all the _impl functions with macros in replace-malloc. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Thu, 25 May 2017 16:47:57 +0900 - rev 361707
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Generate all the _impl functions with macros in replace-malloc. r=njn All the _impl functions in replace-malloc.c are largely identical. This replaces all of them with macro expansions.
899d3cbc450c37b27b7f3def83cc6836a61df09c: Bug 1368932 - Add argument names to malloc implementation declarations in replace-malloc. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Thu, 25 May 2017 16:04:46 +0900 - rev 361706
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Add argument names to malloc implementation declarations in replace-malloc. r=njn This transforms the declarations from e.g.: void *realloc(void *, size_t); into: void *realloc(void *arg1, size_t arg2);
2265602a89551359f9a31fee81887bd9a6360d53: Bug 1368932 - Allow MOZ_PASTE_PREFIX_AND_ARG_COUNT to work with 0 arguments. r=froydnj
Mike Hommey <mh+mozilla@glandium.org> - Thu, 25 May 2017 15:47:21 +0900 - rev 361705
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Allow MOZ_PASTE_PREFIX_AND_ARG_COUNT to work with 0 arguments. r=froydnj At the same time, remove the MOZ_STATIC_ASSERT_VALID_ARG_COUNT, which doesn't actually work for more than 50 arguments(*), and which is now not useful to detect 0 arguments. (*) the build fails, but not directly thanks to the static_assert it expands to.
80496d55346d35f5d14d656acfafff60e0c1870e: Bug 1368932 - Don't rely on the default MALLOC_DECL_VOID for malloc function declarations in replace-malloc. r=njn
Mike Hommey <mh+mozilla@glandium.org> - Thu, 25 May 2017 15:58:56 +0900 - rev 361704
Push 31939 by cbook@mozilla.com at Thu, 01 Jun 2017 11:49:28 +0000
Bug 1368932 - Don't rely on the default MALLOC_DECL_VOID for malloc function declarations in replace-malloc. r=njn In practice, this induces no change in what the expanded code looks like.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip