Skip to content

V
V8
Switch branch/tag
  1. 11 Jan, 2021 19 commits
  3. 10 Jan, 2021 1 commit
  5. 09 Jan, 2021 5 commits
  7. 08 Jan, 2021 15 commits
    • Georgia Kouveli's avatar
      [arm64] Use static_cast instead of reinterpret_cast in CFI code · b3330e95
      Georgia Kouveli authored 
      In a couple of places we cast between uintptr_t and uint64_t with a
reinterpret_cast. While this is correct when these types are aliased
to the same type, if they are defined to be different integral types
(while still of the same size), reinterpet_cast won't work.

Change-Id: I6e935c6c263d8df16f88659ac285faeb5e073add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614678Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#71988}
      b3330e95
    • Seth Brenith's avatar
      [interpreter] Include Star lookahead for more bytecodes · 0d30fac2
      Seth Brenith authored 
      I made some temporary changes in BytecodeArrayWriter to log counts of
how often each pair of bytecodes is adjacent. In data I collected on a
Facebook page with those changes enabled, I noticed that the following
bytecodes were commonly followed by Star, but do not appear in
IsStarLookahead.

LdaImmutableCurrentContextSlot:
  4.4% of all instructions, 66% chance to be followed by Star
CreateClosure:
  3.9% of all instructions, 57% chance to be followed by Star
LdaImmutableContextSlot:
  1.7% of all instructions, 95% chance to be followed by Star
CreateObjectLiteral:
  1.4% of all instructions, 92% chance to be followed by Star
CreateArrayLiteral:
  1.4% of all instructions, 99% chance to be followed by Star
ThrowReferenceErrorIfHole:
  0.7% of all instructions, 100% chance to be followed by Star
GetTemplateObject:
  0.6% of all instructions, 100% chance to be followed by Star
CreateEmptyArrayLiteral:
  0.4% of all instructions, 87% chance to be followed by Star
CreateEmptyObjectLiteral:
  0.2% of all instructions, 79% chance to be followed by Star

I cross-referenced this list with data from google.com and youtube.com
(the top two sites according to Alexa), and found that CreateClosure and
CreateEmpty*Literal are not likely followed by Star on those sites.
Without those three, I suggest that the following bytecode handlers
would likely benefit from Star lookahead:

LdaImmutableCurrentContextSlot
LdaImmutableContextSlot
CreateObjectLiteral
CreateArrayLiteral
ThrowReferenceErrorIfHole
GetTemplateObject

I also ran Octane with --noopt and got the following results.

Name               Median change (95% CI)    U test result
-----------------  ------------------------  -------------------
Richards           +1.02% to +3.28%          improved  p=1.8e-05
DeltaBlue          -1.47% to +0.12%          regressed p=0.05
Crypto             -1.11% to +0.93%          inconclusive
RayTrace           -1.10% to +0.48%          inconclusive
EarleyBoyer        -0.25% to +1.29%          inconclusive
RegExp             -1.46% to +0.08%          inconclusive
Splay              -1.10% to +0.03%          inconclusive
SplayLatency       +0.13% to +0.92%          improved  p=5.8e-05
NavierStokes       -0.22% to +1.24%          inconclusive
PdfJS              -0.69% to +1.04%          inconclusive
Mandreel           -0.66% to +0.66%          inconclusive
MandreelLatency    +0.32% to +1.77%          improved  p=0.00024
Gameboy            -1.13% to +0.38%          inconclusive
CodeLoad           -0.27% to +0.43%          inconclusive
Box2D              -0.53% to +0.82%          inconclusive
zlib               -0.19% to +0.19%          inconclusive
Typescript         -0.23% to +0.59%          inconclusive
Score (version 9)  -0.18% to +0.68%          inconclusive

I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue
agrees that all of the selected bytecodes are likely to precede Star,
but overall I think this change is more benefit than harm.

Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71987}
      0d30fac2
    • Milad Fa's avatar
      PPC/s390: [wasm-simd][liftoff][x64] Prototype load lane · e4675193
      Milad Fa authored 
      Port 5af79398

Original Commit Message:

    Prototype load lane instructions on Liftoff, only for x64.

R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: If9429791139d08a3dd7548220b4eb28e99d6fc7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618241Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71986}
      e4675193
    • Mythri A's avatar
      Disable bytecode flushing once we toggle coverage mode. · 8aa6b15f
      Mythri A authored 
      Changing coverage mode generated different bytecode in some cases.
Hence it is not safe to flush bytecode once we toggle coverage mode.

Bug: chromium:1147917
Change-Id: I9e640aeaec664d3d4a4aaedf809c568e9ad924fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615020
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71985}
      8aa6b15f
    • Jakob Kummerow's avatar
      Reland "[wasm-gc] Liftoff support part 5: i31" · 432c0a78
      Jakob Kummerow authored 
      This is a reland of a3ce2f6d
(No changes; was reverted because a dependency was reverted.)

Original change's description:
> [wasm-gc] Liftoff support part 5: i31
>
> This implements support for i31.get_s and i31.get_u.
>
> Bug: v8:7748
> Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71808}

Bug: v8:7748
Change-Id: Id8e66cab285d2a36fcd712b92a522e83dea93193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617089Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71984}
      432c0a78
    • Junliang Yan's avatar
      s390x: [liftoff] implement stack frame handling · 2651820e
      Junliang Yan authored 
      Change-Id: I68ef1a97ac857106e014d561be3d7e845ec9fbdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618280Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71983}
      2651820e
    • Santiago Aboy Solanes's avatar
      [compiler] Make StringRef::GetFirstChar() return an optional value · 740d94be
      Santiago Aboy Solanes authored 
      Follow-up that continues to make StringRefs's methods return optional
values.

Bug: v8:7790
Change-Id: I34f907810747216b047a3da8db035cf4f62728c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615162Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71982}
      740d94be
    • Benedikt Meurer's avatar
      [inspector] Implement Debug Proxy API via Interceptors. · c27c167c
      Benedikt Meurer authored 
      Previously the Debug Proxy API that's exposed on Wasm frames by
Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
instances. That means that all entities such as "memories", "tables",
"stack", "globals", etc. were JSProxy instances with "get" and "has"
traps. But that has a couple of down-sides:

1. In DevTools front-end, the proxies are shown as JSProxy, which is not
   very useful to developers, since they cannot interact with them nor
   can they inspect their contents. And the object preview also only
   shows "Proxy {}" for them.
2. The performance doesn't scale well, which becomes a painful
   bottleneck with larger Wasm modules that contain hundreds of
   thousands of functions or globals.
3. We cannot use the JSProxy instances in the Scope view (for the
   reasons outlined in 1.) and hence we have different logic to provide
   Scope values than values in the rest of DevTools, which led to subtle
   but annoying bugs and inconsistencies.

This also changes the "locals" implementation by querying the values
ahead of time, similar to the object exposed to the Scope view, instead
of on-demand, since the "locals" object might survive the current
debugger pause and peeking into the stack afterwards would read invalid
memory (and might even be a security issue). For being able to change
locals we need to look into a similar solution as what we have for
JavaScript locals already. The expression stack already works this way.

For performance reasons (especially scaling to huge, realistic Wasm
modules), we cache the per-instance proxies ("functions", "memories",
"tables" and "globals") on the WasmInstanceObject and reuse them (which
is safe since they have a `null` prototype and are non-extensible), and
we also cache the proxy maps (with the interceptors) on the
JSGlobalObject per native context.

Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71981}
      c27c167c
    • Zhi An Ng's avatar
      [wasm-simd][liftoff][x64] Prototype load lane · 5af79398
      Zhi An Ng authored 
      Prototype load lane instructions on Liftoff, only for x64.

Bug: v8:10975
Change-Id: Ifdf58f08b65762d592e99de91c7c622d2a964a9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612335
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71980}
      5af79398
    • Michael Lippautz's avatar
      build: Make cppgc_base a public dependency · 9b057ef1
      Michael Lippautz authored 
      Similar to V8, we provide the include/ headers through a "base" target.

Without this change, `gn check` complains about including cppgc headers
in Blink.

Bug: chromium:1056170
Change-Id: I09ad943cdfedae8c83ab7f957efba796637b8d48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617087Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71979}
      9b057ef1
    • Santiago Aboy Solanes's avatar
      [test] Update MakeExternal tests · 37c3e05e
      Santiago Aboy Solanes authored 
      They weren't initializing the VM at the start of the test. Also updated
the test description.

Bug: v8:7790
Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71978}
      37c3e05e
    • Santiago Aboy Solanes's avatar
      [heap] Don't internalize external uncached Strings · cf49d0d8
      Santiago Aboy Solanes authored 
      In order to avoid internal external uncached Strings, we can copy the
String at the moment of internalizing if it is an external & uncached
String.

Bug: v8:7790
Change-Id: Ie7ed287c105a127b8b4c867aab1a808265a922b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613029
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71977}
      cf49d0d8
    • Zhi An Ng's avatar
      [wasm-simd] Fix loading fp pair registers · 8c698702
      Zhi An Ng authored 
      We were incorrectly clearing the high reg from the list of regs to load.
The intention was to prevent double (and incorrect) loading - loading
128 bits from the low fp and the loading 128 bits from the high fp.
But this violates the assumption that the two regs in a pair would be
set or unset at the same time.

The fix here is to introduce a new enum for register loads, a nop, which
does nothing. The high fp of the fp pair will be tied to this nop, so as
we iterate down the reglist, we load 128 bits using the low fp, then
don't load anything for the high fp.

Bug: chromium:1161654
Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71976}
      8c698702
    • Santiago Aboy Solanes's avatar
      [compiler] Make StringRef::length() return an optional value · d727c9b4
      Santiago Aboy Solanes authored 
      We are planning on moving String to kNeverSerialized. For this, we are
modifying its methods to bail out if they encounter a NeverSerialized
non-internalized String.

Bug: v8:7790
Change-Id: Ia83c1385e53707ddec374e1730963c29b928a08c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615420Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71975}
      d727c9b4
    • Thibaud Michaud's avatar
      [wasm][eh] Allow delegating to the caller · d4ecac6b
      Thibaud Michaud authored 
      Delegating to the current control depth is valid and rethrows the
exception to the caller. See
https://github.com/WebAssembly/exception-handling/pull/143.

R=clemensb@chromium.org
CC=​aheejin@chromium.org

Bug: v8:8091
Change-Id: I6f14663751736ec6de29eefebfccdf5eb9e955e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617081
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71974}
      d4ecac6b