1. 20 Aug, 2020 1 commit
  2. 05 Aug, 2020 1 commit
  3. 21 Jul, 2020 1 commit
    • Jakob Gruber's avatar
      [infra] Add and enable nci_as_highest_tier variant · d1fb6b5a
      Jakob Gruber authored
      With work on NCI proceeding, it makes sense to test multiple
      pipeline configurations.
      
      The nci variant (passes --turbo-nci) now spawns dedicated NCI
      compilation jobs and inserts generated code into the code cache.
      
      The nci_as_highest_tier variant (passes --turbo-nci-as-highest-tier)
      simply replaces TF with NCI code (no extra jobs, no extra caching).
      This mode stresses NCI generated code more than the nci variant, in
      which NCI code only runs on cache hits.
      
      Bug: v8:8888
      Change-Id: I4c2a43cce5271a6c288e7aba195dcc9daed6af9d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299361
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68964}
      d1fb6b5a
  4. 24 Jun, 2020 1 commit
  5. 23 Jun, 2020 1 commit
  6. 22 Jun, 2020 1 commit
  7. 17 Jun, 2020 1 commit
  8. 15 Jun, 2020 1 commit
  9. 09 Jun, 2020 1 commit
  10. 03 Jun, 2020 1 commit
  11. 02 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Support multi-threaded breakpoints · 5fcb414a
      Clemens Backes authored
      This adds support for multiple isolates sharing the same module but
      setting different breakpoints. This is simulated by having a debugger
      test that runs in the "--isolates" variant, i.e. two isolates running
      the same test at the same time. Both isolates will set and remove
      breakpoints.
      
      The DebugInfo will keep a separate list of breakpoints per isolate, and
      when recompiling a function for debugging it will respect all
      breakpoints in all isolates.
      In order to ensure consistency if multiple isolates are setting or
      removing breakpoints simultaneously, we go back to a more coarse-grained
      locking scheme, where the DebugInfo lock is held while re-compiling
      Liftoff functions.
      
      While recompilation will install the code in the module-global code
      table and jump table (and hence all isolates will use it for future
      calls), only the stack of the requesting isolate is rewritten to
      immediately use new code. This is OK, because other isolates are not
      interested in the new breakpoint(s) anyway.
      On {SetBreakpoint}, we always need to rewrite the stack of the
      requesting isolate though, even if the breakpoint was set before by
      another isolate.
      
      Drive-by: Some fixes in SharedFunctionInfo in order to support setting
      breakpoints via the Debug mirror.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: If659afb273260fc5e8124b4b617fb4322de473c7
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218059Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68096}
      5fcb414a
  12. 28 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Support multi-threaded stepping · 97434791
      Clemens Backes authored
      Instead of keeping a single {stepping_frame_} per native module, we now
      keep one frame id per isolate. Hence, each isolate can step through a
      different frame, independent of other isolates.
      The on-stack-replacement of the stepping frame already works on a
      per-isolate basis, since we only replace the return address of a single
      frame, part of the isolate that requested stepping.
      
      The new test (which also executes in a variant with two concurrent
      isolates) revealed some more data races to fix.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68045}
      97434791
  13. 20 May, 2020 1 commit
  14. 19 May, 2020 5 commits
    • Milad Farazmand's avatar
      PPC/s390: Reland "[wasm][debug] Fix tier down during streaming compilation" · 630bad76
      Milad Farazmand authored
      Port 18ac08d0
      
      Original Commit Message:
      
          This is a reland of 3cc981cb with a
          fix for data race detected by TSan.
      
          Original change's description:
          > [wasm][debug] Fix tier down during streaming compilation
          >
          > If the debugger is enabled while streaming compilation is happening, we
          > won't correctly tier down to Liftoff. This is because during streaming
          > compilation, we always compile for no debugging. Fixing that is a bit
          > tricky, since when the debugger is enabled, functions can either already
          > have finished compiling, or they are currently being compiled, or their
          > wire bytes are not received yet.
          > Instead of handling this correctly while streaming compilation is
          > running, we just recompile the whole module with Liftoff after streaming
          > compilation finished.
          >
          > For testing this, we use the existing tests for async compilation, and
          > enable --wasm-test-streaming, which compiles via the streaming decoder
          > even in the async compilation case.
          >
          > R=thibaudm@chromium.org
          >
          > Bug: v8:10531
          > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
          > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
          > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
          > Commit-Queue: Clemens Backes <clemensb@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#67882}
      
      R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I778a10eaba0016a9e897c8f71ac822c6b421350f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208901
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67906}
      630bad76
    • Clemens Backes's avatar
      Reland "[wasm][debug] Fix tier down during streaming compilation" · 18ac08d0
      Clemens Backes authored
      This is a reland of 3cc981cb with a
      fix for data race detected by TSan.
      
      Original change's description:
      > [wasm][debug] Fix tier down during streaming compilation
      >
      > If the debugger is enabled while streaming compilation is happening, we
      > won't correctly tier down to Liftoff. This is because during streaming
      > compilation, we always compile for no debugging. Fixing that is a bit
      > tricky, since when the debugger is enabled, functions can either already
      > have finished compiling, or they are currently being compiled, or their
      > wire bytes are not received yet.
      > Instead of handling this correctly while streaming compilation is
      > running, we just recompile the whole module with Liftoff after streaming
      > compilation finished.
      >
      > For testing this, we use the existing tests for async compilation, and
      > enable --wasm-test-streaming, which compiles via the streaming decoder
      > even in the async compilation case.
      >
      > R=thibaudm@chromium.org
      >
      > Bug: v8:10531
      > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67882}
      
      Bug: v8:10531, v8:10544
      Change-Id: I884922b6ac55543e6ff9b1046438f6b3abab6f64
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207187Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67896}
      18ac08d0
    • Clemens Backes's avatar
      Revert "[wasm][debug] Fix tier down during streaming compilation" · 8d3cca97
      Clemens Backes authored
      This reverts commit 3cc981cb.
      
      Reason for revert: TSan failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/31572
      
      Original change's description:
      > [wasm][debug] Fix tier down during streaming compilation
      > 
      > If the debugger is enabled while streaming compilation is happening, we
      > won't correctly tier down to Liftoff. This is because during streaming
      > compilation, we always compile for no debugging. Fixing that is a bit
      > tricky, since when the debugger is enabled, functions can either already
      > have finished compiling, or they are currently being compiled, or their
      > wire bytes are not received yet.
      > Instead of handling this correctly while streaming compilation is
      > running, we just recompile the whole module with Liftoff after streaming
      > compilation finished.
      > 
      > For testing this, we use the existing tests for async compilation, and
      > enable --wasm-test-streaming, which compiles via the streaming decoder
      > even in the async compilation case.
      > 
      > R=​thibaudm@chromium.org
      > 
      > Bug: v8:10531
      > Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67882}
      
      TBR=clemensb@chromium.org,thibaudm@chromium.org
      
      Change-Id: I26e750c6c6d0783b5e4a0f19a5462a5fbe99a742
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10531
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207186Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67885}
      8d3cca97
    • Clemens Backes's avatar
      [wasm][debug] Fix tier down during streaming compilation · 3cc981cb
      Clemens Backes authored
      If the debugger is enabled while streaming compilation is happening, we
      won't correctly tier down to Liftoff. This is because during streaming
      compilation, we always compile for no debugging. Fixing that is a bit
      tricky, since when the debugger is enabled, functions can either already
      have finished compiling, or they are currently being compiled, or their
      wire bytes are not received yet.
      Instead of handling this correctly while streaming compilation is
      running, we just recompile the whole module with Liftoff after streaming
      compilation finished.
      
      For testing this, we use the existing tests for async compilation, and
      enable --wasm-test-streaming, which compiles via the streaming decoder
      even in the async compilation case.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10531
      Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67882}
      3cc981cb
    • Shu-yu Guo's avatar
      Ship String.prototype.replaceAll · b10ad8b4
      Shu-yu Guo authored
      I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/raep1X9R_SE/m/V8ofHrBdAgAJ
      Bug: v8:9801
      Change-Id: I55e71b37f23ec91a01771f5584d11bc4e5939da4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207920
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67881}
      b10ad8b4
  15. 18 May, 2020 1 commit
  16. 12 May, 2020 1 commit
    • Clemens Backes's avatar
      Reland "[wasm][debug] Fix tier down for multiple isolates" · e62a7f76
      Clemens Backes authored
      This is a reland of 902f48bd, fixed
      to avoid lock inversion problems detected by TSan.
      
      Original change's description:
      > [wasm][debug] Fix tier down for multiple isolates
      >
      > If multiple isolates are using the same module, we need to keep it
      > tiered down as long as any isolate still has a debugger open.
      > Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      > previously triggered tier down might not have finished yet.
      > For now, each isolate starts an independent tier down (i.e. a full
      > recompilation). We could optimize this later by skipping functions that
      > are already tiered down, or are already scheduled for tier down, but we
      > still need to wait for tier-down to finish on each isolate.
      >
      > R=thibaudm@chromium.org
      >
      > Bug: v8:10359
      > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67716}
      
      Bug: v8:10359
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67754}
      e62a7f76
  17. 11 May, 2020 2 commits
    • Shu-yu Guo's avatar
      Revert "[wasm][debug] Fix tier down for multiple isolates" · 131fa2c9
      Shu-yu Guo authored
      This reverts commit 902f48bd.
      
      Reason for revert: Made TSAN unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/9480
      
      Original change's description:
      > [wasm][debug] Fix tier down for multiple isolates
      > 
      > If multiple isolates are using the same module, we need to keep it
      > tiered down as long as any isolate still has a debugger open.
      > Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      > previously triggered tier down might not have finished yet.
      > For now, each isolate starts an independent tier down (i.e. a full
      > recompilation). We could optimize this later by skipping functions that
      > are already tiered down, or are already scheduled for tier down, but we
      > still need to wait for tier-down to finish on each isolate.
      > 
      > R=​thibaudm@chromium.org
      > 
      > Bug: v8:10359
      > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67716}
      
      TBR=clemensb@chromium.org,thibaudm@chromium.org
      
      Change-Id: Ibf650e8b6143471b44f2822c1737e7de5f8bdb20
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10359
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194372Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67720}
      131fa2c9
    • Clemens Backes's avatar
      [wasm][debug] Fix tier down for multiple isolates · 902f48bd
      Clemens Backes authored
      If multiple isolates are using the same module, we need to keep it
      tiered down as long as any isolate still has a debugger open.
      Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      previously triggered tier down might not have finished yet.
      For now, each isolate starts an independent tier down (i.e. a full
      recompilation). We could optimize this later by skipping functions that
      are already tiered down, or are already scheduled for tier down, but we
      still need to wait for tier-down to finish on each isolate.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67716}
      902f48bd
  18. 06 May, 2020 1 commit
    • Jakob Gruber's avatar
      [snapshot] Clear reconstructable data prior to d8 stress_snapshot run · 3c422d1c
      Jakob Gruber authored
      The serializer currently cannot handle a heap state containing
      arbitrary compiled Code objects. As a quick fix for the
      --stress-snapshot d8 flag, we clear compiled data from the isolate
      prior to the serialize-deserialize-verify pass.
      
      With this change, mjsunit tests pass on x64.
      
      The %SerializeDeserializeNow() runtime function would require more
      work, since it is not possible to mutate the heap to this extent while
      still preserving a runnable host context and isolate. We will need
      another solution there.
      
      Drive-by: Skip the stress_snapshot variant except for the mjsunit
      suite.
      
      Tbr: machenbach@chromium.org
      Bug: v8:10493,v8:10416
      Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67585}
      3c422d1c
  19. 01 May, 2020 1 commit
    • Seth Brenith's avatar
      [debug] Don't crash when breaking on entry to functions with heap vars · 3c20dfed
      Seth Brenith authored
      Any function with heap-allocated variables starts by creating and
      pushing a new context for its execution. When entering the debugger due
      to the stack check in the beginning of InterpreterEntryTrampoline, the
      function has not yet had a chance to push that new context. The code in
      ScopeIterator currently assumes that any function which needs a context
      already has one by the time the debugger attempts to iterate scopes, but
      in this case that assumption is invalid, which can cause a null deref.
      
      This change introduces a new function ScopeIterator::NeedsAndHasContext
      to replace previous calls to current_scope_->NeedsContext(). This new
      function checks for the case where the current scope matches the closure
      scope but the context matches the containing context for the function,
      which implies that the function has not yet pushed its own context.
      
      Bug: v8:10319, chromium:1038747
      Change-Id: I29636f269c44d35b68d8446769d17170eed50e89
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168021
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67519}
      3c20dfed
  20. 30 Apr, 2020 1 commit
  21. 16 Apr, 2020 3 commits
  22. 15 Apr, 2020 1 commit
  23. 14 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Store whether code was generated for debugging · 4721585b
      Clemens Backes authored
      This adds a flag to {WasmCode} objects to store whether this code was
      generated for debugging. This flag can be set for Liftoff code (in which
      case the code will e.g. have an extended prologue for debugging), but it
      can also be set for TurboFan, in case Liftoff bailed out when producing
      the debugging code.
      
      Having this flag allows us to remove the hack to pass the compilation
      results to {OnFinishedUnits} just to check whether we actually wanted to
      compile Liftoff functions.
      
      Drive-by: Replace the {ReachedRecompilationTierField} by a
      {MissingRecompilationField}, because all we need to know is if we are
      still waiting for that function to get recompiled.
      
      R=ahaas@chromium.org
      
      Bug: v8:10330,v8:10410
      Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67119}
      4721585b
  24. 08 Apr, 2020 5 commits
  25. 06 Apr, 2020 1 commit
  26. 30 Mar, 2020 1 commit
  27. 09 Mar, 2020 1 commit
  28. 18 Feb, 2020 1 commit
  29. 09 Feb, 2020 1 commit