Skip to content

V
V8
Switch branch/tag
  1. 05 Aug, 2021 6 commits
  3. 04 Aug, 2021 31 commits
  5. 03 Aug, 2021 3 commits
    • Omer Katz's avatar
      cppgc: Handle low-address stack in write barrier. · 649d3c10
      Omer Katz authored 
      Windows can allocate the stack at low addresses. A low-address on-stack
slot (e.g. backing store reference for Blink's on-heap collections) with
a null value would make TryGetCagedHeap falsely think that the slot
resides in a caged heap that starts at a null address.

We will still crash for low-address on-stack slots with non-null
on-stack value, since these cases are not considered valid and should
not happen.

The null value check is added only to Windows. It is not an issue on
other OSes where the stack always resides at high addresses and we
prefer to keep the write barrier as cheap as possible.

Bug: chromium:1230794, chromium:1056170
Change-Id: I07e2d178cd95edba57015d6bc6eb127a443b0589
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069146
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76069}
      649d3c10
    • Lu Yahan's avatar
      [riscv64] Add baseline_riscv64_inl.h into BUILD.gn · 8fbf1e7d
      Lu Yahan authored 
      Change-Id: I82464ad3ae81843b8e3ac940c079218a55aad67e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041145
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarJi Qiu <qiuji@iscas.ac.cn>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76068}
      8fbf1e7d
    • Seth Brenith's avatar
      Iterate in assembly order for jump threading · fcc81d9a
      Seth Brenith authored 
      While reading through the jump threading implementation, I noticed
something strange: ApplyForwarding iterates through the block list in
reverse post-order, not in assembly order. Thus, the value prev_fallthru
might not refer to the previous block in assembly order. Obviously it
works fine this way or we would have noticed by now, but I think that
this step would be a little easier to read and reason about if the
iteration used assembly order instead.

I've added a test case to demonstrate the difference when using
assembly order: in a diamond where the right side starts with an empty
deferred block, the current implementation would fail to replace that
block with a nop. I doubt this case would have any real-world impact.

Change-Id: I28abe2043434debb54896871d15c540ad52c6368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039261
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76067}
      fcc81d9a