1. 03 Feb, 2020 14 commits
    • Michael Lippautz's avatar
      heap: Improved incremental scheduling for unified heap · bd02f663
      Michael Lippautz authored
      When the embedder integrates in V8's garbage collector the performance
      of the atomic phase is sensitive to how much embedder memory is found
      through marking the overall transitive closure.
      
      Before this patch, V8 would help out tracing the embedder's heap when
      making progress through tasks but not on allocations. In addition, V8
      would complete the garbage collection when it has observed it's own
      marking worklists as empty 3 times (*). This can create performance
      cliffs when there's a lot of work still to be done on the embedder
      side.
      
      This patch adds helping steps on allocation that are proportional to
      the bytes that V8 would otherwise process, guaranteeing some progress
      as long as there's V8 allocations. This allows us to remove (*).
      
      Potential Tradeoffs:
      - More time spent in V8's garbage collection metrics as we slightly
        limit the chances for the embedder to mark objects through tasks.
      - Prolonged V8.execute time (JS execution)
      + Faster progress
      + Less memory
      + Smaller atomic pause time
      
      Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
      Bug: chromium:1044630
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66091}
      bd02f663
    • Ng Zhi An's avatar
      Reland "[wasm-simd][liftoff] Check CpuFeatures for SIMD support" · cccbd5f1
      Ng Zhi An authored
      This relands commit 7c32fa05.
      
      Some test cases need to be updated, since we will bail out to TurboFan
      where previously Liftoff was happy to run, when SIMD is not supported.
      
      Original change's description:
      > [wasm-simd][liftoff] Check CpuFeatures for SIMD support
      >
      > If Wasm simd128 is not supported on this particular hardware, we bail
      > out to TurboFan.
      >
      > Bug: v8:9909
      > Change-Id: Ie46e154426783ba099b7c0facc906670cda1bdd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029427
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66055}
      
      Bug: v8:9909
      Bug: v8:10169
      Change-Id: I850e1fe6bfbd12fb2eec052aa8367624c09f7a08
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030354
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66090}
      cccbd5f1
    • Jakob Kummerow's avatar
      [test] Skip memory-hungry test on Android · bdac09e4
      Jakob Kummerow authored
      After allowing larger strings on 64-bit builds, this test OOMs on
      Android devices that don't have enough memory.
      
      Tbr: machenbach@chromium.org
      Change-Id: I05c44d7074388a4306e5266ba1aa9da760c83377
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035877Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66089}
      bdac09e4
    • Ng Zhi An's avatar
      Fix assembler for sqrtpd · d05d335e
      Ng Zhi An authored
      The assembly of sqrtpd when using Sqrtpd macro was wrong, since
      Sqrtpd(xmm1, xmm1) will incorrect generated vsqrtpd(xmm1, xmm1, xmm1),
      which is nonsensical, since vsqrtpd only takes two operands. The
      expected instruction should be vsqrtpd(xmm1, xmm0, xmm1) in terms of the
      encoding, which is vsqrtpd(xmm1, xmm1).
      
      So, move sqrtpd and cvtps2dq out into their own macro list, because
      they have two operands in their AVX form, unlike the rest of the
      instructions in SSE2_INSTRUCTION_LIST.
      
      Also updated disasm and tests to use this new list.
      
      Fixed: v8:10170
      Change-Id: Ia9343c9a3ae64596bbc876744556e1dcea2a443b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032195Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66088}
      d05d335e
    • Ng Zhi An's avatar
      [wasm-simd] Unify sse and avx impl for i32x4 shifts · 90830b59
      Ng Zhi An authored
      The implementation is pretty much the same, and we instead delegate to a
      macro assembler to decide if we want the sse or avx instruction.
      
      This unification will simplify optimization of constant shifts later on.
      
      Bug: v8:10115
      Change-Id: If9a17519a746f0a8474e75dbdebb8e4f5b0d07c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026469Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66087}
      90830b59
    • Ng Zhi An's avatar
      [wasm-simd] Force some shuffles to use register for src0 and src1 · e8bba383
      Ng Zhi An authored
      test-run-wasm-simd/RunWasm_S8x16MultiShuffleFuzz_turbofan was failing
      reliably with --no-enable-avx. (Even though the shuffle sequences were
      randomly generated, in practice we quite quickly hit a case where we
      will get a segfault.)
      
      For 32x4swizzle and 32x4 shuffle, they use pshufd, which can take an
      operand, but needs to be 16-byte aligned, which they are not, current.
      So force them to be registers for now. This is similar to what we do in
      the x64 selection too.
      
      Bug: v8:9198
      Change-Id: If319ff276202d4be095714a6cb18dec0d0551efd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032202Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66086}
      e8bba383
    • Michael Achenbach's avatar
      [foozzie] Compare output before crashes · 3fd58c66
      Michael Achenbach authored
      Crashes in the presence of RangeError happen often during differential
      fuzzing. Until now we have ignored such cases completely.
      
      After this change we compare as much output as possible when one or
      both runs have crashed, dramatically increasing the coverage.
      
      No-Try: true
      Bug: chromium:1048099
      Change-Id: I923c10e9064b5dc6cae1e39a254e221d2867e0e7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030914
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66085}
      3fd58c66
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      Sigurd Schneider authored
      This CL implements functionality to allow an embedder to mark a
      debug scope as terminate-on-resume. This results in a termination
      exception when that debug scope is left and execution is resumed.
      Execution of JavaScript remains possible after a debug scope is
      marked as terminate-on-resume (but before execution of the paused
      code resumes).
      This is used by blink to correctly prevent resuming JavaScript
      execution upon reload while being paused at a breakpoint.
      
      This is important for handling reloads while paused at a breakpoint
      in blink. The resume command terminates blink's nested message loop
      that is used while to keep the frame responsive while the debugger
      is paused. But if a reload is triggered while execution is paused
      on a breakpoint, but before execution is actually resumed from the
       breakpoint (that means before returning into the V8 JavaScript
      frames that are paused on the stack below the C++ frames that belong
      to the nested message loop), we re-enter V8 to do tear-down actions
      of the old frame. In this case Runtime.terminateExecution() cannot be
      used before Debugger.resume(), because the tear-down actions that
      re-enter V8 would trigger the termination exception and crash the
      browser (because the browser expected the tear-down to succeed).
      
      Hence we introduce this flag on V8 that says: It is OK if someone
      re-enters V8 (to execute JS), but upon resuming from the breakpoint
      (i.e. returning to the paused frames that are on the stack below),
      generate a termination exception.
      
      We deliberated adding a corresponding logic on the blink side (instead
      of V8) but we think this is the simplest solution.
      
      More details in the design doc:
      
      https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
      
      Bug: chromium:1004038, chromium:1014415
      
      Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
    • Jakob Kummerow's avatar
      [ptr-compr] Bump max string length to ~2**29 · ea56bf55
      Jakob Kummerow authored
      Without pointer compression, the max string length on 64-bit platforms
      used to be 2**30 (minus header). With pointer-compression, this was
      accidentally lowered to 2**28 (which is the historical limit for 32-bit
      platforms). This CL bumps the limit on 64-bit platforms to 2**29, which
      is the maximum we can support given that any heap object's size in bytes
      must fit into a Smi (which are now 31-bit on all 64-bit platforms, with
      or without pointer compression).
      
      Change-Id: I263544317d9e6137f6b6a044784a21f41a2761b0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030916Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66083}
      ea56bf55
    • Georgia Kouveli's avatar
      [arm64] Add support for BTI instruction · 4eac274d
      Georgia Kouveli authored
      Bug: v8:10026
      Change-Id: I8ee836ee6298415a21cf487bc3d0e5f803fc6186
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965590
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66082}
      4eac274d
    • Thibaud Michaud's avatar
      Reland "Reland "[wasm] Cache streaming compilation result"" · ab6c4669
      Thibaud Michaud authored
      This is a reland of 9781aa07
      
      Original change's description:
      > Reland "[wasm] Cache streaming compilation result"
      >
      > This is a reland of 015f379a
      >
      > Original change's description:
      > > [wasm] Cache streaming compilation result
      > >
      > > Before compiling the code section, check whether the
      > > bytes received so far match a cached module. If they do, delay
      > > compilation until we receive the full bytes, since we are likely to find
      > > a cache entry for them.
      > >
      > > R=clemensb@chromium.org
      > >
      > > Bug: v8:6847
      > > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66000}
      >
      > Bug: v8:6847
      > Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66047}
      
      Bug: v8:6847
      Change-Id: I272f56eee28010f34cc99df475164581c8b63036
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66081}
      ab6c4669
    • Michael Lippautz's avatar
      heap: Avoid scanning on-stack reference on incremental marking start · aa376ae0
      Michael Lippautz authored
      Similar to other stack references they don't need to be scanned on incremental
      marking start.
      
      Bug: chromium:1046277
      Change-Id: I9fb3ee768df0288b5a61f09e680e321a8cb7b895
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030915Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66080}
      aa376ae0
    • Pierre Langlois's avatar
      [arm64][simulator] Enable LOG_ALL with the debugger 'trace' command. · 82bf9151
      Pierre Langlois authored
      When enabling tracing with the debugger 'trace' command, enable logging
      everything instead of just disassembly and general purpose registers. This is
      not only more useful but also consistent with the --trace-sim flag.
      
      Change-Id: I4537ceed30edc63f4b3f39f1958ebef0cb303bf1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033172Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66079}
      82bf9151
    • Dan Elphick's avatar
      [compiler] Make StateValuesAccess methods inlinable · 14d1b9e9
      Dan Elphick authored
      This moves several simple StateValuesAccess methods as well as
      SparseInputMask::InputIterator::IsReal into their header files so they
      can be more easily inlined. This gives about a 7% improvement to the
      BackgroundSelectInstructions runtime call stat.
      
      Also marks some methods called by the new methods as V8_PRIVATE_EXPORT
      so component build test can build.
      
      Bug: v8:10051
      Change-Id: I3e34977a4fa660d3f4f55fd4f2c0b2370d5d2bc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023559Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66078}
      14d1b9e9
  2. 02 Feb, 2020 2 commits
  3. 01 Feb, 2020 1 commit
  4. 31 Jan, 2020 15 commits
  5. 30 Jan, 2020 8 commits