Rationalize base/allocator/page_allocator.h API semantics |
||
Issue descriptionThere has been a lot of back-and-forth over the last few months about the meaning of "committed" memory and how it affects the PartitionAllocator and PageAllocator APIs. I'd like to rework the PageAllocator API so that we have a consistent set of concepts. Avoiding any currently used terms, there seem to be 4 fundamental memory operations: (1) Assign/Unassign Virtual Memory ranges (2) Change access permissions on a range (page really) (3) Back a VM range with physical ram or swap (4) Hint the kernel that a region does NOT need to be paged out to disk. The current API provides various combinations of the above operations, but aren't super clear about the distinction leading to some bugs. For example, DecommitSystemPages() provides 2, 3, and 4 on Windows (it returns the pages to OS, allows the kernel to skip a page-out, AND makes them inaccessible so they fault on next access). However on POSIX, it only provides 3 and 4. This leads to code like: https://chromium.googlesource.com/chromium/src/+/6936cdeeb4d83d7857b64aa634ac15c599d8b48d/third_party/WebKit/Source/platform/heap/PageMemory.cpp#27 and https://chromium.googlesource.com/chromium/src/+/6936cdeeb4d83d7857b64aa634ac15c599d8b48d/third_party/WebKit/Source/platform/heap/PageMemory.cpp#20 which causes a redundant call in Windows to provide the right protection on POSIX. I don't quite have an exact plan yet on how to restructure the API, but as a first step, I want to detangle the semantic mix-up for DecommitSystemPages() between Windows and Posix. After that, depending on how the rest of the usage looks, I'm hoping to migrate the API (and terminology) over to something that consistently represents the above 4 operations without accidentally implying the wrong thing by using platform-specific terminology like "Commit". Will start next week as I'm out this one. Feel free to add comments or questions.
,
Sep 19 2017
,
Sep 26 2017
Been analyzing this more. I think there are 3 things to do right now. (1) Split out a page_allocator_internal.h and/or partition_allocator_internal.h so it's more clear what's a public API and what's not. Maybe even introduce an internal namespace (2) Redo a bunch of terms. "Page" and "System" seem to be used in all sorts of confusing ways that casual readers don't expect. (3) Fix the DecommitSystemPages() API and DiscardSystemPages() API so they do consistent things on different platforms. Gonna start that down path.
,
Oct 2 2017
Spent a few days on that rabbit hole. There's a lot of tangled bits between the unittest and the API because so many of the functions have been "public" for so long. Gonna focus instead on just fixing DecommitSystemPages() and DiscardSystemPages() for now. Will try to clean up the API later.
,
Oct 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/94795ee343292fce4a11a04d1129f7c6d3612f44 commit 94795ee343292fce4a11a04d1129f7c6d3612f44 Author: Albert J. Wong <ajwong@chromium.org> Date: Mon Oct 02 20:40:06 2017 Remove ADL usage in PartitionAlloc calls. Some accidental uses of ADL for resolving PartitionAlloc API calls accidentally snuck in. This removes them. Bug: 766882 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I5998cfa3a13eafc444fe97ff447fbb8f35ef7b4e Reviewed-on: https://chromium-review.googlesource.com/686175 Reviewed-by: Albert J. Wong <ajwong@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Commit-Queue: Albert J. Wong <ajwong@chromium.org> Cr-Commit-Position: refs/heads/master@{#505769} [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/core/layout/line/InlineBox.cpp [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/core/paint/PaintLayer.cpp [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/platform/text/BidiCharacterRun.cpp [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/platform/wtf/allocator/Partitions.cpp [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/platform/wtf/allocator/Partitions.h [modify] https://crrev.com/94795ee343292fce4a11a04d1129f7c6d3612f44/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBufferContents.cpp
,
Oct 2 2017
As part of the unification of V8 and Blink memory allocation, we'll need to support V8's VirtualMemory abstraction. Here's a link to the code: https://cs.chromium.org/chromium/src/v8/src/allocation.cc?rcl=98b4a1f8e5ccaff301baa194dc03ba08a79cc741&l=109 Right now, this uses the V8 platform definitions for a bunch of allocation functions - we'll need the equivalent in page_allocator: void* OS::Allocate(const size_t requested, size_t* allocated, OS::MemoryPermission access, void* hint); void* OS::ReserveRegion(size_t size, void* hint); void* OS::ReserveAlignedRegion(size_t size, size_t alignment, void* hint, size_t* allocated); bool OS::CommitRegion(void* address, size_t size, bool is_executable); bool OS::UncommitRegion(void* address, size_t size); bool OS::ReleaseRegion(void* address, size_t size); bool OS::ReleasePartialRegion(void* address, size_t size); bool OS::HasLazyCommits(); https://cs.chromium.org/chromium/src/v8/src/base/platform/platform-linux.cc?rcl=98b4a1f8e5ccaff301baa194dc03ba08a79cc741&l=112
,
Oct 2 2017
That's basically the API was going to move towards....though with the addition of Discard().
,
Oct 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a24491093779658b7392f2718e691203bd45fcb commit 8a24491093779658b7392f2718e691203bd45fcb Author: Albert J. Wong <ajwong@chromium.org> Date: Tue Oct 17 06:55:31 2017 PageAllocator: Fix DecommitSystemPages() semantics Prior to this CL, DecommitSystemPages() performed 2 conceptually different operations that callers cared about depending on which platorm it was called on. There are 2 operations: * return storage from ram or swap to the OS * make the page inaccessible. On Windows, "Committed memory" is a first-class concept in the OS Memory Subsystem API. A region returned via VirtualAlloc() when MEM_COMMIT is specified is guaranteed to be touchable without causing the program to crash due to out of memory. Since it is a first class concept, decommitting is directly supported and calling this function resulted in the both operations above. In the POSIX memory API, there is no such thing as "Committed memory." Until the first touch of an anonymous mmap()ed region, it is unknown if the pointer deference for that address may crash. Therefore this API had unclear semantics and was implemented to ONLY return allocated ram and swap to the OS. Page permissions were left the same meaning subsequent touches would just reallocate the memory instead of fault. This divergence in page accessibility caused callers to manually execute SetSystemPagesAccess() after calling DecommitSystemPages() to ensure uniform behavior across all platforms which resulted in a wasted syscall on Windows and confusing API semantics. This CL changes the contract of DecommitSystemPages() so that it provides the guarnatees that can be enforced on all platforms. The naming is still somewhat incorrect as "commit" is not a well defined concept in POSIX...baby steps... Bug: 766882 Change-Id: Ib5c8f1c712e080f1003fad628f60012e0feaf9d8 Reviewed-on: https://chromium-review.googlesource.com/696292 Commit-Queue: Albert J. Wong <ajwong@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Albert J. Wong <ajwong@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#509309} [modify] https://crrev.com/8a24491093779658b7392f2718e691203bd45fcb/base/allocator/partition_allocator/page_allocator.cc [modify] https://crrev.com/8a24491093779658b7392f2718e691203bd45fcb/base/allocator/partition_allocator/page_allocator.h [modify] https://crrev.com/8a24491093779658b7392f2718e691203bd45fcb/third_party/WebKit/Source/platform/heap/HeapPage.cpp [modify] https://crrev.com/8a24491093779658b7392f2718e691203bd45fcb/third_party/WebKit/Source/platform/heap/PageMemory.cpp
,
Nov 2 2017
crbug.com/775949 and crbug.com/776755 found that commit 8a24491093779658b7392f2718e691203bd45fcb caused a regression in android system_health.mobile_memory as well as dromaeo.domcoremodify. The previous commit consisted of 2 things: (1) some pure refactors of code in {Decommit,Discard}SystemPages (2) Changing DecommitSystemPages()'s semantics in POSIX to match that of windows such that decommmitting a region makes it inaccessible. Going to try to break apart those changes and commit them separately.
,
Nov 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6742ab502e29fd55e2cd569286c5fbef5e311760 commit 6742ab502e29fd55e2cd569286c5fbef5e311760 Author: Albert J. Wong <ajwong@chromium.org> Date: Mon Nov 06 23:30:27 2017 PageAllocator: Refactor {Decommit,Discard}SystemPages(). Original commit is 8a24491093779658b7392f2718e691203bd45fcb The original commit caused an unexpected regression in system_health.memory_mobile (crbug.com/775949) and dromaeo.domcoremodify ( crbug.com/776755 ). This patch is the subset of the functionality that is just be a pure refactor. Bug: 766882 Change-Id: I44b0ef79847bd572784f253f20858cc788d93fb8 Reviewed-on: https://chromium-review.googlesource.com/752191 Commit-Queue: Albert J. Wong <ajwong@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Reviewed-by: Albert J. Wong <ajwong@chromium.org> Cr-Commit-Position: refs/heads/master@{#514291} [modify] https://crrev.com/6742ab502e29fd55e2cd569286c5fbef5e311760/base/allocator/partition_allocator/page_allocator.cc [modify] https://crrev.com/6742ab502e29fd55e2cd569286c5fbef5e311760/base/allocator/partition_allocator/page_allocator.h [modify] https://crrev.com/6742ab502e29fd55e2cd569286c5fbef5e311760/third_party/WebKit/Source/platform/heap/HeapPage.cpp
,
Nov 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/be7b68a78100830d2cf97319ca2aee64cf4f3edb commit be7b68a78100830d2cf97319ca2aee64cf4f3edb Author: Chris Palmer <palmer@chromium.org> Date: Tue Nov 07 22:50:24 2017 [Partition Alloc] Don't redundantly call madvise redundantly. When #ifndef MADV_FREE #define MADV_FREE MADV_DONTNEED #endif we would call madvise(..., MADV_FREE); and then, if that failed, call madvise(..., MADV_DONTNEED). This would result in pointlessly calling madvise(..., MADV_DONTNEED) and then trying again instead of CHECKing immediately. This is more of a readability refactor than a performance-relevant change, obviously. Thanks to ajwong for noticing this! BUG=766882, 755284 Change-Id: If8cbe14f38dfe2bd126bc24f79e670c45b29c8d5 Reviewed-on: https://chromium-review.googlesource.com/754038 Reviewed-by: Primiano Tucci <primiano@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#514635} [modify] https://crrev.com/be7b68a78100830d2cf97319ca2aee64cf4f3edb/base/allocator/partition_allocator/page_allocator.cc
,
Nov 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/85ec7854664107ae9f5285b8febb97d5d1f5a0ae commit 85ec7854664107ae9f5285b8febb97d5d1f5a0ae Author: Chris Palmer <palmer@chromium.org> Date: Thu Nov 09 04:06:10 2017 Revert "[Partition Alloc] Don't redundantly call madvise redundantly." This reverts commit be7b68a78100830d2cf97319ca2aee64cf4f3edb. Reason for revert: Lost the crucial CHECK(!ret) in a merge conflict, and re-adding it causes macOS to fail (EINVAL, invalid address). That requires further investigation. Original change's description: > [Partition Alloc] Don't redundantly call madvise redundantly. > > When > > #ifndef MADV_FREE > #define MADV_FREE MADV_DONTNEED > #endif > > we would call madvise(..., MADV_FREE); and then, if that failed, call > madvise(..., MADV_DONTNEED). This would result in pointlessly calling > madvise(..., MADV_DONTNEED) and then trying again instead of CHECKing > immediately. > > This is more of a readability refactor than a performance-relevant change, > obviously. > > Thanks to ajwong for noticing this! > > BUG=766882, 755284 > > Change-Id: If8cbe14f38dfe2bd126bc24f79e670c45b29c8d5 > Reviewed-on: https://chromium-review.googlesource.com/754038 > Reviewed-by: Primiano Tucci <primiano@chromium.org> > Reviewed-by: Kentaro Hara <haraken@chromium.org> > Commit-Queue: Chris Palmer <palmer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#514635} TBR=ajwong@chromium.org,palmer@chromium.org,primiano@chromium.org,haraken@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 766882, 755284 Change-Id: I2b71c2f6773c38109d17c151e5a81aa50bc46b10 Reviewed-on: https://chromium-review.googlesource.com/759058 Reviewed-by: Chris Palmer <palmer@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Albert J. Wong <ajwong@chromium.org> Commit-Queue: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#515091} [modify] https://crrev.com/85ec7854664107ae9f5285b8febb97d5d1f5a0ae/base/allocator/partition_allocator/page_allocator.cc
,
Mar 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7a10b50820c00aef915ca3e15b1c8481e4d90c54 commit 7a10b50820c00aef915ca3e15b1c8481e4d90c54 Author: Chris Palmer <palmer@chromium.org> Date: Sat Mar 24 00:46:05 2018 [Partition Alloc] Refactor page_allocator*.{cc,h} somewhat. We were in a maze of twisty #ifdefs, all alike. We are now somewhat less likely to be eaten by a grue. TBR=dcheng Bug: 766882 Change-Id: Ib72010a76cdf76fc1ec821b618cc0ad967d687ab Reviewed-on: https://chromium-review.googlesource.com/978860 Commit-Queue: Chris Palmer <palmer@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#545651} [modify] https://crrev.com/7a10b50820c00aef915ca3e15b1c8481e4d90c54/base/BUILD.gn [modify] https://crrev.com/7a10b50820c00aef915ca3e15b1c8481e4d90c54/base/allocator/partition_allocator/page_allocator.cc [add] https://crrev.com/7a10b50820c00aef915ca3e15b1c8481e4d90c54/base/allocator/partition_allocator/page_allocator_internals_posix.h [add] https://crrev.com/7a10b50820c00aef915ca3e15b1c8481e4d90c54/base/allocator/partition_allocator/page_allocator_internals_win.h
,
Mar 26 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/22034ca8368c9a687da33f96c5330d39aca424c3 commit 22034ca8368c9a687da33f96c5330d39aca424c3 Author: Mostyn Bramley-Moore <mostynb@vewd.com> Date: Mon Mar 26 11:40:29 2018 [jumbo] don't #include inside namespaces Speculative mac jumbo fix after this CL: https://chromium-review.googlesource.com/c/chromium/src/+/978860/ TBR=palmer@chromium.org Bug: 766882 Change-Id: I673edfd250987cd654e45c13b749f800438e2313 Reviewed-on: https://chromium-review.googlesource.com/979806 Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Reviewed-by: Daniel Bratell <bratell@opera.com> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#545761} [modify] https://crrev.com/22034ca8368c9a687da33f96c5330d39aca424c3/base/BUILD.gn [modify] https://crrev.com/22034ca8368c9a687da33f96c5330d39aca424c3/base/allocator/partition_allocator/page_allocator.cc [add] https://crrev.com/22034ca8368c9a687da33f96c5330d39aca424c3/base/allocator/partition_allocator/page_allocator_internal.h [modify] https://crrev.com/22034ca8368c9a687da33f96c5330d39aca424c3/base/allocator/partition_allocator/page_allocator_internals_posix.h [modify] https://crrev.com/22034ca8368c9a687da33f96c5330d39aca424c3/base/allocator/partition_allocator/page_allocator_internals_win.h
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4c197977f4ec1cd3b5d09f5a999287f56857b09 commit a4c197977f4ec1cd3b5d09f5a999287f56857b09 Author: Albert J. Wong <ajwong@chromium.org> Date: Tue May 01 18:29:21 2018 Shatter partition_alloc.h into smaller files. partition_alloc.h has been a dumping ground for all objects related to PartitonAlloc. The original code used many inlined top-level functions making the implementation very coupled. This splits out most of the critical clusters of functionality into separate files with roughly one struct/class per file. The split makes the module layering and interaction boundaries much clearer. Because of the heavy use of inlining, and the highly coupled nature of the original code, it was not possible to make a clean split yet between declaration and implementation. Therefore, this splitting required introducing "-inl.h" files because too many of these objects reached direclty into each others's fields. These "-inl.h" files can likely be reduced in future refactors. Bug: 766882 Change-Id: Iceeccc64a1d810a68cedfb28599dfbcf66642b98 Reviewed-on: https://chromium-review.googlesource.com/1006154 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#555118} [modify] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/BUILD.gn [modify] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/page_allocator.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/page_allocator_constants.h [modify] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_alloc.cc [modify] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_alloc.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_alloc_constants.h [modify] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_alloc_unittest.cc [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_bucket-inl.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_bucket.cc [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_bucket.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_cookie.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_direct_map_extent-inl.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_direct_map_extent.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_freelist_entry.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_oom.cc [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_oom.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_page-inl.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_page.cc [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_page.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_root_base-inl.h [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_root_base.cc [add] https://crrev.com/a4c197977f4ec1cd3b5d09f5a999287f56857b09/base/allocator/partition_allocator/partition_root_base.h
,
May 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c commit d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c Author: Albert J. Wong <ajwong@chromium.org> Date: Wed May 02 01:40:04 2018 Remove -inl.h files from Partition Alloc. Now that the module boundaries are clear, refactor some functions to make a clear layer separation for types and remove the -inl.h files. Yay! \o/ Bug: 766882 Change-Id: I17934666c640c8f5daed40c2c8435b2e220b7b79 Reviewed-on: https://chromium-review.googlesource.com/1008964 Commit-Queue: Albert J. Wong <ajwong@chromium.org> Reviewed-by: Chris Palmer <palmer@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Cr-Commit-Position: refs/heads/master@{#555277} [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/BUILD.gn [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_alloc.cc [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_alloc.h [delete] https://crrev.com/1b809b07759de3771b97dfe4f8853f11616c6f06/base/allocator/partition_allocator/partition_bucket-inl.h [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_bucket.cc [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_bucket.h [delete] https://crrev.com/1b809b07759de3771b97dfe4f8853f11616c6f06/base/allocator/partition_allocator/partition_direct_map_extent-inl.h [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_direct_map_extent.h [delete] https://crrev.com/1b809b07759de3771b97dfe4f8853f11616c6f06/base/allocator/partition_allocator/partition_page-inl.h [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_page.cc [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_page.h [delete] https://crrev.com/1b809b07759de3771b97dfe4f8853f11616c6f06/base/allocator/partition_allocator/partition_root_base-inl.h [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_root_base.cc [modify] https://crrev.com/d02466c63d5cf7bc7b3d4e8b2332d3bf7bf3386c/base/allocator/partition_allocator/partition_root_base.h |
||
►
Sign in to add a comment |
||
Comment 1 by ajwong@chromium.org
, Sep 19 2017