|
|
Created:
4 years, 11 months ago by Michael Lippautz Modified:
4 years, 11 months ago Reviewers:
Hannes Payer (out of office) CC:
v8-reviews_googlegroups.com, Hannes Payer (out of office), ulan Base URL:
https://chromium.googlesource.com/v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
Description[heap] Sort sweep pages list by free memory.
Also restrict how many pages are swept during slow path allocation.
BUG=chromium:524425
LOG=N
Committed: https://crrev.com/2e481c15b77e733c8313ddc2c1e2ef9fda773b31
Cr-Commit-Position: refs/heads/master@{#33435}
Patch Set 1 #
Total comments: 11
Patch Set 2 : Addressed comments #Patch Set 3 : Fixed compilation #
Total comments: 1
Patch Set 4 : Adressed final comment #
Messages
Total messages: 25 (12 generated)
mlippautz@chromium.org changed reviewers: + hpayer@chromium.org
- Performance neutral on a single run on v8.infinite_scroll. - Performance neutral on the microbenchmarks - Sorting the pages is below 20us, even for larger chunks (~100 pages)
https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc File src/heap/mark-compact.cc (right): https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... src/heap/mark-compact.cc:3762: void MarkCompactCollector::MoveEvacuationCandidatesToEndOfPagesList() { This logic is not needed anymore, since we have a sweeping todo list. https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... src/heap/mark-compact.cc:3799: for (Page* p : sweeping_list(space)) { Since we have now a separate data structure, why don't we remove entries from the data structure in a synchronized way? https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc File src/heap/spaces.cc (right): https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc#newcode2851 src/heap/spaces.cc:2851: size_in_bytes, 1); 1 should be a constant. https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc#newcode2852 src/heap/spaces.cc:2852: if (max_freed >= size_in_bytes) { If you add this case, you want to call RefillFreeList(); after SweepInParallel. https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.h File src/heap/spaces.h (left): https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.h#oldcode2208 src/heap/spaces.h:2208: // end_of_unswept_pages_ page. Good by, end_of_unswept_pages_.
PTAL https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc File src/heap/mark-compact.cc (right): https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... src/heap/mark-compact.cc:3762: void MarkCompactCollector::MoveEvacuationCandidatesToEndOfPagesList() { On 2016/01/20 09:25:03, Hannes Payer wrote: > This logic is not needed anymore, since we have a sweeping todo list. Done. https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... src/heap/mark-compact.cc:3799: for (Page* p : sweeping_list(space)) { On 2016/01/20 09:25:03, Hannes Payer wrote: > Since we have now a separate data structure, why don't we remove entries from > the data structure in a synchronized way? Because removing items from a std::vector can be quite expensive. Since those calls are interleaving (and unbalanced) we might end up removing an item in the middle, resulting in expensive move operations in the vector. (And iterating should be fast in this case.) https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc File src/heap/spaces.cc (right): https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc#newcode2851 src/heap/spaces.cc:2851: size_in_bytes, 1); On 2016/01/20 09:25:03, Hannes Payer wrote: > 1 should be a constant. Done: kMaxPagesSweptDuringSlowAllocation https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.cc#newcode2852 src/heap/spaces.cc:2852: if (max_freed >= size_in_bytes) { On 2016/01/20 09:25:03, Hannes Payer wrote: > If you add this case, you want to call RefillFreeList(); after SweepInParallel. Done. (ftr: this is to move over already freed memory, in case we need them in following allocations) https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.h File src/heap/spaces.h (left): https://codereview.chromium.org/1596343004/diff/1/src/heap/spaces.h#oldcode2208 src/heap/spaces.h:2208: // end_of_unswept_pages_ page. On 2016/01/20 09:25:03, Hannes Payer wrote: > Good by, end_of_unswept_pages_. Done.
Description was changed from ========== [heap] Sorted sweep pages list by free memory. Also restrict how much pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ========== to ========== [heap] Sort sweep pages list by free memory. Also restrict how much pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ==========
Description was changed from ========== [heap] Sort sweep pages list by free memory. Also restrict how much pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ========== to ========== [heap] Sort sweep pages list by free memory. Also restrict how mny pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ==========
Description was changed from ========== [heap] Sort sweep pages list by free memory. Also restrict how mny pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ========== to ========== [heap] Sort sweep pages list by free memory. Also restrict how many pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ==========
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1596343004/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1596343004/20001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_compile_dbg on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_compile_dbg/builds/1...)
The CQ bit was checked by mlippautz@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1596343004/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1596343004/40001
https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc File src/heap/mark-compact.cc (right): https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... src/heap/mark-compact.cc:3799: for (Page* p : sweeping_list(space)) { On 2016/01/20 11:11:16, Michael Lippautz wrote: > On 2016/01/20 09:25:03, Hannes Payer wrote: > > Since we have now a separate data structure, why don't we remove entries from > > the data structure in a synchronized way? > > Because removing items from a std::vector can be quite expensive. Since those > calls are interleaving (and unbalanced) we might end up removing an item in the > middle, resulting in expensive move operations in the vector. > > (And iterating should be fast in this case.) Why don't we use a priority_queue?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
On 2016/01/20 12:08:19, Hannes Payer wrote: > https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc > File src/heap/mark-compact.cc (right): > > https://codereview.chromium.org/1596343004/diff/1/src/heap/mark-compact.cc#ne... > src/heap/mark-compact.cc:3799: for (Page* p : sweeping_list(space)) { > On 2016/01/20 11:11:16, Michael Lippautz wrote: > > On 2016/01/20 09:25:03, Hannes Payer wrote: > > > Since we have now a separate data structure, why don't we remove entries > from > > > the data structure in a synchronized way? > > > > Because removing items from a std::vector can be quite expensive. Since those > > calls are interleaving (and unbalanced) we might end up removing an item in > the > > middle, resulting in expensive move operations in the vector. > > > > (And iterating should be fast in this case.) > > Why don't we use a priority_queue? As discussed offline, let's keep the vector for now. The reasons are: - Priority queue does not provide random access, but rather push/pop - We would need to sync the priority queue, but cannot get rid of synchronization on page level as we have another entry point to sweeping - We need to finalize on page level for WAS_SWEPT (which we cannot get rid of unless we make live_bytes atomic). So we need to keep a list of pages that have been swept.
lgtm https://codereview.chromium.org/1596343004/diff/40001/src/heap/spaces.h File src/heap/spaces.h (right): https://codereview.chromium.org/1596343004/diff/40001/src/heap/spaces.h#newco... src/heap/spaces.h:2146: static const int kMaxPagesSweptDuringSlowAllocation = 1; This one can be local in the function.
The CQ bit was checked by mlippautz@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from hpayer@chromium.org Link to the patchset: https://codereview.chromium.org/1596343004/#ps60001 (title: "Adressed final comment")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1596343004/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1596343004/60001
Message was sent while issue was closed.
Description was changed from ========== [heap] Sort sweep pages list by free memory. Also restrict how many pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ========== to ========== [heap] Sort sweep pages list by free memory. Also restrict how many pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ==========
Message was sent while issue was closed.
Committed patchset #4 (id:60001)
Message was sent while issue was closed.
Description was changed from ========== [heap] Sort sweep pages list by free memory. Also restrict how many pages are swept during slow path allocation. BUG=chromium:524425 LOG=N ========== to ========== [heap] Sort sweep pages list by free memory. Also restrict how many pages are swept during slow path allocation. BUG=chromium:524425 LOG=N Committed: https://crrev.com/2e481c15b77e733c8313ddc2c1e2ef9fda773b31 Cr-Commit-Position: refs/heads/master@{#33435} ==========
Message was sent while issue was closed.
Patchset 4 (id:??) landed as https://crrev.com/2e481c15b77e733c8313ddc2c1e2ef9fda773b31 Cr-Commit-Position: refs/heads/master@{#33435} |