Skip to content

V
V8
Switch branch/tag
  1. 31 May, 2021 20 commits
  3. 30 May, 2021 2 commits
  5. 29 May, 2021 2 commits
  7. 28 May, 2021 6 commits
  9. 27 May, 2021 10 commits
    • Paolo Severini's avatar
      [fastcall] Resolve CFunction overloads based on arity · 3e12e60a
      Paolo Severini authored 
      To support Fast API calls with overloads, implement compile-time
function resolution based on the number of arguments passed to the JS
function.

Bug: v8:11739
Change-Id: I96839dc0b6fc540eff94573ac9e77f678908fc3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2901249Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74837}
      3e12e60a
    • Dominik Inführ's avatar
      [heap] Turn backing_store_bytes_ into uint64_t · 0ebe286f
      Dominik Inführ authored 
      The counter as size_t can legitimately overflow on 32-bit systems, since
decreasing the counters is performed after all backing stores were
freed on a background thread. Before sweeping is finished a new backing
store could already be allocated which then leads to the overflow.

Bug: v8:11788, chromium:1211437
Change-Id: Id9f3e58b0e84e831fe47109f7deb3a05ae7e489c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922242
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74836}
      0ebe286f
    • Nico Hartmann's avatar
      [TurboFan] Remove incorrect CHECK for VerifyType in Verifier · 11f331de
      Nico Hartmann authored 
      Bug: chromium:1212550
Change-Id: Ia3750305542caff97aeb83c078238c41cd2761d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919963
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74835}
      11f331de
    • Milad Fa's avatar
      PPC/s390: [codegen] Assert that RegisterArray has only unique registers · d48c0b45
      Milad Fa authored 
      Port 032ab3d2

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

Change-Id: I075377afc65999731223f4dce368e6aca4e784ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2920810Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74834}
      d48c0b45
    • Milad Fa's avatar
      s390: [codegen] Remove extra value during dcheck · 781c3ee6
      Milad Fa authored 
      Port 34b1c557

Original Commit Message:

    as arguments. The currently can be the same and thus we don't add any
    additional DHCECKs there.

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

Change-Id: Icd0baf83cf2deeee5f7bfe19902484b6e073e833
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922311Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74833}
      781c3ee6
    • Adam Klein's avatar
      Revert "[builtins][x64] Use callee-saved registers for write barrier stubs" · d23d68fe
      Adam Klein authored 
      This reverts commit 17915002.

Reason for revert: Breaks TSAN builds (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20builder/19166/overview)

Original change's description:
> [builtins][x64] Use callee-saved registers for write barrier stubs
>
> Calls to the record write stub are quite frequent and the caller has to
> save all registers used by the builtin.
>
> This CL moves the register saving to the builtin itself, reducing the
> call-site code size significantly in many cases and thus improving
> compilation speed of sparkplug.
>
> Follow-up CLs with introduce the same behaviour to other platforms.
>
> - CallRecordWriteStubSaveRegisters preserves the existing behaviour and
>   saves clobbered registers.
> - CallRecordWriteStub expects the registers to match the ones specified
>   in the WriteBarrierDescriptor for more compact code.
>
> Bug: v8:11420
> Change-Id: Ib1260cf972712bb9ba879beacd34b06a7fa347f1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922103
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74831}

Bug: v8:11420
Change-Id: I20f239e64ec2834acd651341634974291992add5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922316
Auto-Submit: Adam Klein <adamk@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74832}
      d23d68fe
    • Camillo Bruni's avatar
      [builtins][x64] Use callee-saved registers for write barrier stubs · 17915002
      Camillo Bruni authored 
      Calls to the record write stub are quite frequent and the caller has to
save all registers used by the builtin.

This CL moves the register saving to the builtin itself, reducing the
call-site code size significantly in many cases and thus improving
compilation speed of sparkplug.

Follow-up CLs with introduce the same behaviour to other platforms.

- CallRecordWriteStubSaveRegisters preserves the existing behaviour and
  saves clobbered registers.
- CallRecordWriteStub expects the registers to match the ones specified
  in the WriteBarrierDescriptor for more compact code.

Bug: v8:11420
Change-Id: Ib1260cf972712bb9ba879beacd34b06a7fa347f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922103Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74831}
      17915002
    • Omer Katz's avatar
      cppgc, heap: Implement UMA reporting for cppgc library. · 88e5b8f5
      Omer Katz authored 
      This CL does 2 things:
1) Implements forwarding of histogram reporting from cppgc to v8 via
CppHeap.
2) Establishes the pipeline in GCTracer for sending the histograms to
the embedder.

Currently only cppgc histograms are populated.

See crrev.com/c/2916956 for usage.

Bug: chromium:1154636
Change-Id: I8150116f757e105d0dfac96a3f6e7dd95717f5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917033
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74830}
      88e5b8f5
    • Daniel Lehmann's avatar
      [wasm] publish TurboFan results in batches · 990c9386
      Daniel Lehmann authored 
      With mprotect-based write protection of the WebAssembly code space,
we switch page protection flags each time (at least) one compilation
thread needs write access. Two such switches happen when TurboFan
compilation results are available in {ExecuteCompilationUnits}: One
switch happens when calling {NativeModule::AddCompiledCode} and one more
when calling {NativeModule::PublishCode} via
{SchedulePublishCompilationResults} and {PublishCompilationResults}.

So far, each TurboFan result was published eagerly, i.e., as soon as it
became available. This has the benefit that faster code is available
immediately, and had no large cost or downside without write protection.
However, with write protection switching permissions is expensive (an
mprotect syscall) and needs to lock the
{WasmCodeAllocator::allocation_mutex_} (which causes lock contention and
under Linux many futex syscalls). Thus, immediately publishing each
TurboFan result when using write protection can cause up to 10x slower
compilation compared with not using write protection. In terms of
syscalls we measured (non scientifically) with
{sudo perf stat -e 'syscalls:sys_enter*' d8 ...} on the Unity benchmark:
- mprotect: 10k vs. 44k syscalls (baseline vs. write protection)
- futex: 31k vs. 112k syscalls (baseline vs. write protection)
- sys time: 1.6s vs. 10s (baseline vs. write protection)
All of those are clearly to high.

The fix here is simply to batch togther multiple TurboFan functions into
one publishing step when using write protection. The batching logic
already exists for Liftoff, so we can just disable eager publishing for
TurboFan when using write protection. Additionally, we publish once when
all Liftoff results are available (even if the batch is not complete),
such that time-to-execute is not regressed.

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

Bug: v8:11663, chromium:932033
Change-Id: Ibf6f28ecf4733b40322e62761e66046dec60a125
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922114
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74829}
      990c9386
    • Clemens Backes's avatar
      Revert "[flags] Predictable should not imply single-threaded" · ab4986b8
      Clemens Backes authored 
      This reverts commit 5fd38582.

Reason for revert: Failures on the predictable bot: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20predictable/36749/overview

Original change's description:
> [flags] Predictable should not imply single-threaded
>
> The --predictable flag is often used to reproduce issues, and having it
> imply --single-threaded can change decisions like which compiler(s) to
> use. This is because --single-threaded is meant to be set by embedders
> (hence we do our best to support single-threaded execution), whereas
> --predictable is a testing-only flag which should not change semantics
> too much. The fact that --predictable executes everything in a single
> thread is already implied by the PredictablePlatform.
>
> R=​ahaas@chromium.org, machenbach@chromium.org
> CC=​​jkummerow@chromium.org
>
> Change-Id: Ic174dd59dfdbd6aa1a410f983db05db26c944cd5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919828
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74822}

Change-Id: Id312cd2b3a150fa3e61daf6550651dc252264ca2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922248
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74828}
      ab4986b8