Skip to content

V
V8
Switch branch/tag
  1. 18 Nov, 2019 1 commit
    • Michael Achenbach's avatar
      Revert "[heap] Reduce size of possibly empty buckets" · 37e62175
      Michael Achenbach authored 
      This reverts commit 80caf2cf.

Reason for revert: Breaks gpu tests:
https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5570
# Debug check failed: !possibly_empty_buckets->Contains(bucket_index).

Original change's description:
> [heap] Reduce size of possibly empty buckets
> 
> Before this CL a byte was used per bucket to store whether the bucket
> is possibly empty or not. This CL changes this such that each bucket
> only needs a single bit.
> 
> PossiblyEmptyBuckets is now a word in the page header. If more bits
> are needed than fit into a single word, an external bitmap is
> allocated using AlignedAlloc. Storing this on the page header, allows
> to remove initial_buckets from the SlotSet. The SlotSet allocation is
> then again a power-of-2 in release mode.
> 
> Change-Id: If61fd5cfa153f98757beeb444a530f6e2803fdb6
> Bug: chromium:1023139
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906376
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64991}

TBR=ulan@chromium.org,dinfuehr@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:1023139
Change-Id: Ia90b07b9562af934dacba012da31e4f172f2922d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918258Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65001}
      37e62175
  3. 16 Nov, 2019 1 commit
    • Dominik Inführ's avatar
      [heap] Reduce size of possibly empty buckets · 80caf2cf
      Dominik Inführ authored 
      Before this CL a byte was used per bucket to store whether the bucket
is possibly empty or not. This CL changes this such that each bucket
only needs a single bit.

PossiblyEmptyBuckets is now a word in the page header. If more bits
are needed than fit into a single word, an external bitmap is
allocated using AlignedAlloc. Storing this on the page header, allows
to remove initial_buckets from the SlotSet. The SlotSet allocation is
then again a power-of-2 in release mode.

Change-Id: If61fd5cfa153f98757beeb444a530f6e2803fdb6
Bug: chromium:1023139
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906376
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64991}
      80caf2cf
  5. 15 Nov, 2019 1 commit
  7. 05 Nov, 2019 1 commit
    • Dominik Inführ's avatar
      [heap] Avoid iterating all pages when freeing empty buckets · add50f20
      Dominik Inführ authored 
      At the end of scavenge, the GC iterates all pages to search for empty
buckets and free them. With this CL the scavenger marks buckets
(and their corresponding pages) that were empty to reduce work.
After finishing scavenging the GC only needs to revisit those marked
buckets.

Unlike (minor) mark-compact, the scavenger can't directly free those
buckets, since the evacuation and pointer updating-phases are
not separated.

Right now the pages are processed sequentially but this could be
parallelized in a subsequent CL.

Change-Id: I47ed8c0e952b06c5d960e39a6f38e745d5618656
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889884
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64781}
      add50f20
  9. 30 Oct, 2019 1 commit
  11. 09 Oct, 2019 1 commit
    • Dominik Inführ's avatar
      [heap] Do not calculate SlotSet in RecordWrite · 84ec511b
      Dominik Inführ authored 
      Since SlotSet is just an array of Buckets, RecordWrite doesn't need
to calculate the SlotSet-address in the SlotSet-array. bucket_index is
now directly calculated from the offset of the slot from the start of
the page. bucket_index may therefore now also exceed SlotSet::kBuckets,
for large objects.

Also calculate cell_offset and bit_index from page_start_offset, it is
not necessary to truncate page_start_offset to MemoryChunk::kPageSize.

Bug: v8:9454
Change-Id: I17edeafa4681a6348482c64dd0616065ce3121c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849525
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64197}
      84ec511b
  13. 07 Oct, 2019 2 commits
  15. 04 Oct, 2019 2 commits
  17. 30 Sep, 2019 1 commit
  19. 26 Sep, 2019 1 commit
  21. 25 Sep, 2019 1 commit
  23. 13 Sep, 2019 1 commit
  25. 02 Aug, 2019 1 commit
  27. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored 
      This is a reland of 658ff200

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored 
      This reverts commit 658ff200.

Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=​yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

TBR=yangguo@chromium.org,clemensh@chromium.org

Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored 
      We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.

Before:
  class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
  using MyBitField = BitField<int, 6, 4, MyEnum>;

This might reduce compilation time by reducing the number of existing
classes.

The old pattern is forbidden now by making {BitField} final.

R=yangguo@chromium.org

Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  29. 23 May, 2019 1 commit
  31. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored 
      Failure addressed by not exposing the new test to the jitless environment.
(jgruber@ on TBR).

New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
compressed pointers in generated code. Enum name EMBEDDED_OBJECT
changed to FULL_EMBEDDED_OBJECT.

RelocInfo::[set_]target_object() abstract away the difference between
FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.

Compressed embedded objects can only be created at this time on
x64 with pointer compression turned on. Arm64 constant pools don't
support compressed objects at this time.

NOPRESUBMIT=true

Bug: v8:7703
TBR: jgruber@chromium.org
Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  33. 29 Apr, 2019 2 commits
  35. 29 Mar, 2019 1 commit
  37. 06 Mar, 2019 1 commit
  39. 19 Dec, 2018 1 commit
  41. 13 Dec, 2018 1 commit
  43. 12 Dec, 2018 1 commit
  45. 10 Dec, 2018 1 commit
  47. 21 Nov, 2018 1 commit
    • Ulan Degenbaev's avatar
      [heap] Clean up TypedSlotSet. · 841c40b7
      Ulan Degenbaev authored 
      This extracts the parts of the TypedSlotSet that are used only
sequentially into a separate class called TypedSlots.

The new class will be used in the concurrent marker to keep track of
typed slots locally and then to merge them to the main remembered set
during finalization of marking.

The patch also cleans up atomics in the Iterate and ClearInvalidSlots
methods that can run concurrently to each other.

Bug:v8:8459

Change-Id: Id7a63041f7b99218381e5e9e1999210cab9c4369
Reviewed-on: https://chromium-review.googlesource.com/c/1340247
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57673}
      841c40b7
  49. 24 Oct, 2018 1 commit
  51. 12 Oct, 2018 1 commit
  53. 02 Feb, 2018 1 commit
  55. 06 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[bits] Consolidate Count{Leading,Trailing}Zeros" · 27ffc624
      Clemens Hammacher authored 
      This is a reland of 7d231e57, fixed to
avoid instantiating CountLeadingZeros for bits==0.

Original change's description:
> [bits] Consolidate Count{Leading,Trailing}Zeros
> 
> Instead of having one method for 32 bit integers and one for 64 bit,
> plus a templatized version to choose from those two, just implement one
> version which handles unsigned integers of any size. Also, make them
> constexpr.
> The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
> order to keep the amount of code changes small. Also, sometimes it
> improves readability by stating exactly the size of the argument,
> especially for leading zeros (where zero-extending would add more
> leading zeros).
> 
> CountLeadingZeros now uses a binary search inspired implementation
> as proposed in Hacker's Delight. It's more than 20% faster on x64 if
> the builtins are disabled.
> CountTrailingZeros falls back to CountPopulation instead of counting in
> a naive loop. This is ~50% faster.
> 
> R=mstarzinger@chromium.org
> 
> Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
> Reviewed-on: https://chromium-review.googlesource.com/741231
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49106}

Change-Id: Icdff2510ec66d1c96a1912cef29d77d8550994ee
Reviewed-on: https://chromium-review.googlesource.com/753903Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49138}
      27ffc624
  57. 04 Nov, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[bits] Consolidate Count{Leading,Trailing}Zeros" · 1a1968fe
      Michael Achenbach authored 
      This reverts commit 7d231e57.

Reason for revert: Breaks revert for win-clang:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/342755

Original change's description:
> [bits] Consolidate Count{Leading,Trailing}Zeros
> 
> Instead of having one method for 32 bit integers and one for 64 bit,
> plus a templatized version to choose from those two, just implement one
> version which handles unsigned integers of any size. Also, make them
> constexpr.
> The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
> order to keep the amount of code changes small. Also, sometimes it
> improves readability by stating exactly the size of the argument,
> especially for leading zeros (where zero-extending would add more
> leading zeros).
> 
> CountLeadingZeros now uses a binary search inspired implementation
> as proposed in Hacker's Delight. It's more than 20% faster on x64 if
> the builtins are disabled.
> CountTrailingZeros falls back to CountPopulation instead of counting in
> a naive loop. This is ~50% faster.
> 
> R=​mstarzinger@chromium.org
> 
> Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
> Reviewed-on: https://chromium-review.googlesource.com/741231
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49106}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: Iceeb35bf9c7539a1013c9bdbc47118008611bef2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/753463Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49123}
      1a1968fe
  59. 03 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      [bits] Consolidate Count{Leading,Trailing}Zeros · 7d231e57
      Clemens Hammacher authored 
      Instead of having one method for 32 bit integers and one for 64 bit,
plus a templatized version to choose from those two, just implement one
version which handles unsigned integers of any size. Also, make them
constexpr.
The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
order to keep the amount of code changes small. Also, sometimes it
improves readability by stating exactly the size of the argument,
especially for leading zeros (where zero-extending would add more
leading zeros).

CountLeadingZeros now uses a binary search inspired implementation
as proposed in Hacker's Delight. It's more than 20% faster on x64 if
the builtins are disabled.
CountTrailingZeros falls back to CountPopulation instead of counting in
a naive loop. This is ~50% faster.

R=mstarzinger@chromium.org

Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
Reviewed-on: https://chromium-review.googlesource.com/741231Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49106}
      7d231e57
  61. 15 Sep, 2017 1 commit
    • Ulan Degenbaev's avatar
      [heap] Fix memory leak in the remembered set. · 163d3604
      Ulan Degenbaev authored 
      Empty slot set buckets can leak in the following scenarios.

Scenario 1 (large object space):
1) A large array is allocated in the large object space.
2) The array is filled with old->new references, which allocates new
   slot set buckets.
3) The references are overwritten with smis or old space pointers, which
   make the slots set buckets empty.
4) Garbage collection (scavenge or mark-compact) iterates the slots set
   of the array and pre-frees the empty buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for large object space in mark-compact. 

Scenario 2 (no mark-compact):
1) A small array is allocated in the old space.
2) The array is filled with old->new references, which allocates new
   slot set buckets.
3) The references are overwritten with smis or old space pointers, which
   make the slots set buckets empty.
4) Scavenge iterates the slots set of the array and pre-frees the empty
   buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for swept pages in scavenger.

Bug: v8:6800
TBR: mlippautz@chromium.org
Change-Id: I48d94870f5acf4f6208858271886911c895a9126
Reviewed-on: https://chromium-review.googlesource.com/668442Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48041}
      163d3604
  63. 16 Aug, 2017 1 commit
  65. 03 Aug, 2017 1 commit
  67. 02 Aug, 2017 2 commits