1. 26 Apr, 2022 4 commits
    • Jakob Kummerow's avatar
      [wasm-gc] Fix roundtrips of JS functions through Wasm · bac984e6
      Jakob Kummerow authored
      When passing anyref-typed things to Wasm, we cannot expect that
      all functions are WasmExternalFunctions. Instead of adding a
      relatively expensive type check to such calls, this patch disables
      function unwrapping for anyref-typed values.
      
      Fixed: v8:12789
      Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80179}
      bac984e6
    • Victor Gomes's avatar
      [maglev] Add Box/UnboxNumbers and Float64Add nodes · 755b7d86
      Victor Gomes authored
      - For simplicity we call a builtin when allocating a number.
      - Elision of boxing/unboxing nodes will be done in a followup CL.
      
      Bug: v8:7700
      Change-Id: Iec4422d84c6597d3369ab512a1662adb0f077c98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602514Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Auto-Submit: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80178}
      755b7d86
    • Andreas Haas's avatar
      [wasm] Fix argument count of Table.set · 2f535cdf
      Andreas Haas authored
      Table.set has two arguments, the table index and the value. Therefore
      Table.set was defined with a length of 2. However, the value argument is
      optional, so the length should actually be 1.
      
      Change-Id: Ica2ea13a8e78c974cb011df2b5dc99f8e7eb4bcd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398496Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80176}
      2f535cdf
    • Jakob Gruber's avatar
      Reland "[osr] Use the new OSR cache" · 91453880
      Jakob Gruber authored
      This is a reland of commit 91da3883
      
      Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
      on arm64.
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80167}
      91453880
  2. 25 Apr, 2022 7 commits
    • Shu-yu Guo's avatar
      Plumb Isolate through own property enumeration functions · 0407423b
      Shu-yu Guo authored
      Currently the Isolate is gotten off of the object that the operation is
      being performed on. Shared objects return the shared Isolate, which is
      incorrect as it shouldn't be used to run JS, nor does it have
      HandleScopes open. Plumb the executing Isolate through.
      
      Bug: v8:12547
      Change-Id: I3d960751c798ac657a6122598154e36d9d504c31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606489Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80163}
      0407423b
    • Nico Hartmann's avatar
      Revert "[osr] Use the new OSR cache" · c34b7b41
      Nico Hartmann authored
      This reverts commit 91da3883.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
      
      Original change's description:
      > [osr] Use the new OSR cache
      >
      > This CL switches over our OSR system to be based on the feedback
      > vector osr caches.
      >
      > - OSRing to Sparkplug is fully separated from OSR urgency. If
      >   SP code exists, we simply jump to it, no need to maintain an
      >   installation request.
      > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
      >   If a valid target code object exists, we enter it *without*
      >   calling into runtime to fetch the code object.
      > - Finally, OSR urgency still remains as the heuristic for
      >   requesting Turbofan OSR compile jobs. Note it no longer has a
      >   double purpose of being a generic untargeted installation
      >   request.
      >
      > With the new system in place, we can remove now-unnecessary
      > hacks:
      >
      > - Early OSR tierup is replaced by the standard OSR system. Any
      >   present OSR code is automatically entered.
      > - The synchronous OSR compilation fallback is removed. With
      >   precise installation (= per-JumpLoop-bytecode) we no longer
      >   have the problem of 'getting unlucky' with JumpLoop/cache entry
      >   mismatches. Execution has moved on while compiling? Simply spawn
      >   a new concurrent compile job.
      > - Remove the synchronous (non-OSR) Turbofan compile request now
      >   that we always enter available OSR code as early as possible.
      > - Tiering into Sparkplug no longer messes with OSR state.
      >
      > Bug: v8:12161
      > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Auto-Submit: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80147}
      
      Bug: v8:12161
      Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@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/main@{#80148}
      c34b7b41
    • Jakob Gruber's avatar
      [osr] Use the new OSR cache · 91da3883
      Jakob Gruber authored
      This CL switches over our OSR system to be based on the feedback
      vector osr caches.
      
      - OSRing to Sparkplug is fully separated from OSR urgency. If
        SP code exists, we simply jump to it, no need to maintain an
        installation request.
      - Each JumpLoop checks its dedicated FeedbackVector cache slot.
        If a valid target code object exists, we enter it *without*
        calling into runtime to fetch the code object.
      - Finally, OSR urgency still remains as the heuristic for
        requesting Turbofan OSR compile jobs. Note it no longer has a
        double purpose of being a generic untargeted installation
        request.
      
      With the new system in place, we can remove now-unnecessary
      hacks:
      
      - Early OSR tierup is replaced by the standard OSR system. Any
        present OSR code is automatically entered.
      - The synchronous OSR compilation fallback is removed. With
        precise installation (= per-JumpLoop-bytecode) we no longer
        have the problem of 'getting unlucky' with JumpLoop/cache entry
        mismatches. Execution has moved on while compiling? Simply spawn
        a new concurrent compile job.
      - Remove the synchronous (non-OSR) Turbofan compile request now
        that we always enter available OSR code as early as possible.
      - Tiering into Sparkplug no longer messes with OSR state.
      
      Bug: v8:12161
      Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80147}
      91da3883
    • Marja Hölttä's avatar
      [rab/gsab] Atomics.wait + waitAsync: Support GSAB · 2176ead6
      Marja Hölttä authored
      Bug: v8:11111
      Change-Id: Ifb3776bce308d869064120d5e28a2ea7df943757
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578652Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80142}
      2176ead6
    • jameslahm's avatar
      Reland "[interpreter] Optimize strict equal boolean" · fce1047f
      jameslahm authored
      This is a reland of commit 62632c08.
      Reason for previous revert: Performance regressions crbug.com/1315724.
      The reland only optimizes strict equal boolean literal like "a===true"
      or "a===false", and we generate TestReferenceEqual rather than
      TestStrictEqual for the comparasion. And also add typed optimization
      for ReferenceEqual when all inputs are boolean with boolean constant.
      
      Original change's description:
      > [interpreter] Optimize strict equal boolean
      >
      > For strict equal boolean literal like "a===true"
      > or "a===false", we could generate TestReferenceEqual
      > rather than TestStrictEqual. And in `execution_result()->IsTest()`
      > case, we could directly emit JumpIfTrue/JumpIfFalse.
      >
      > E.g.
      > ```
      > a === true
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > ```
      > To:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestReferenceEqual
      > ```
      >
      > E.g.
      > ```
      > if (a === true)
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > JumpIfFalse
      > ```
      > To
      > ```
      > LdaGlobal
      > JumpIfTrue
      > Jump
      > ```
      >
      >
      > Bug: v8:6403
      > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: 王澳 <wangao.james@bytedance.com>
      > Cr-Commit-Position: refs/heads/main@{#79935}
      
      Bug: v8:6403
      Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80141}
      fce1047f
    • Tobias Tebbi's avatar
      [turboshaft] initial commit · e4cc6ed4
      Tobias Tebbi authored
      TurboShaft is a new, CFG-based IR for TurboFan.
      This CL adds the basic IR and bidirectional translation from/to
      TurboFan's sea-of-nodes-based IR for some common operators (still
      incomplete even for JS).
      
      Bug: v8:12783
      Change-Id: I162fdf10d583a9275a9f655f5b44b888faf813f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563562Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80136}
      e4cc6ed4
    • jameslahm's avatar
      [web-snapshot] Fix snapshot scope info in Context · 0dbe7257
      jameslahm authored
      - In DeserializeContext, scope info local values
      snapshot is in order of `name,value,name,value`,
      and we should ReadValue after ReadString.
      
      - Support non-inlined ScopeInfo locals, use
      NameToIndexHashTable to serialize and deserialize
      scope info local values when its local count is
      more than kScopeInfoMaxInlinedLocalNamesSize.
      
      Bug: v8:11525, v8:12820
      Change-Id: I6ea2c498b594bed7ba8ca5be6af2ab9f0d39aa2b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600531Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: 王澳 <wangao.james@bytedance.com>
      Cr-Commit-Position: refs/heads/main@{#80130}
      0dbe7257
  3. 22 Apr, 2022 3 commits
  4. 21 Apr, 2022 3 commits
    • Tobias Tebbi's avatar
      [test] skip regress/regress-crbug-1239907 on TSAN · 4e9cb635
      Tobias Tebbi authored
      Bug: v8:12822
      Change-Id: Idc8225640e132d175d2c06b530d77fcda7362b55
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599486
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80092}
      4e9cb635
    • Leszek Swirski's avatar
      [maglev] Implement LdaContextSlot · 88976125
      Leszek Swirski authored
      In the simplest way possible.
      
      Bug: v8:7700
      Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80089}
      88976125
    • Leszek Swirski's avatar
      [maglev] Start implenting inlining · c0a63243
      Leszek Swirski authored
      Add a --maglev-inlining flag, and add some half-baked support for
      inlining functions when there is call feedback.
      
      When the flag is enabled and there is call feedback, we create a nested
      MaglevGraphBuilder for the current graph, and pause building the graph
      of the outer function. We manually set up its prologue to set up its
      frame with the arguments pass into the call, build the body with the
      nested graph builder. This inner builder knows that it is building an
      inlined function, and all Return bytecodes will instead emit a Jump to a
      single merge block at the end of the function, where execution of the
      outer function can resume.
      
      These inner function basic blocks are wired into the outer graph with
      new JumpToInline and JumpFromInline control nodes. The idea is that
      subsequent passes will know what the inline function is, and will use
      these to manage the function stack (particularly for codegen and
      especially deopts).
      
      Bug: v8:7700
      Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80077}
      c0a63243
  5. 20 Apr, 2022 3 commits
  6. 12 Apr, 2022 1 commit
  7. 11 Apr, 2022 1 commit
  8. 09 Apr, 2022 1 commit
  9. 07 Apr, 2022 2 commits
  10. 06 Apr, 2022 7 commits
  11. 05 Apr, 2022 4 commits
  12. 04 Apr, 2022 4 commits
    • Benedikt Meurer's avatar
      Preserve "proper method names" as-is in error.stack. · ad21d212
      Benedikt Meurer authored
      This changes the logic for generating method names in `error.stack` to
      prepend an inferred type name only when the function name is a valid
      ECMAScript identifiers and does not equal the inferred type name, to
      
      (1) give developers more control over the exact name shown in
          `error.stack`, as well as
      (2) avoid confusion in the presence of renaming of local variables.
      
      Previously we'd leave the function name as-is if it was prefixed by the
      inferred type name, but that condition is unnecessarily strict, and led
      to a bunch of inconsistencies around special names like
      `<instance_member_initializer>` where this dynamic approached often
      prefixed it with the correct type name, but also sometimes got it wrong
      and prepended `Object.`, which is very unfortunate and misleading.
      Specifically for these special names, we'll add logic later in the
      parser to infer a useful (complete) name.
      
      The design doc (https://bit.ly/devtools-method-names-in-stack-traces)
      contains more background and examples of why we do this change.
      
      Doc: https://bit.ly/devtools-method-names-in-stack-traces
      Fixed: chromium:1294619
      Bug: chromium:1283435
      Change-Id: Ib8b528ba25255dcd07e9d11044c562c11d699bcb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565724Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79748}
      ad21d212
    • Jakob Gruber's avatar
      Reland "[osr] Basic support for concurrent OSR" · d187c6c2
      Jakob Gruber authored
      This is a reland of commit 3ce690ee
      
      Changed for the reland:
      - Remove the currently-unused BytecodeArray member to avoid MSAN
        failures.
      - s/return/continue/ in optimizing-compile-dispatcher.
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161
      Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79746}
      d187c6c2
    • Nikolaos Papaspyrou's avatar
      test: Remove two obsolete regression tests · 173885cd
      Nikolaos Papaspyrou authored
      This CL removes two obsolete regression tests that were taking too
      long on debug engine builds.
      
      Bug: v8:12753
      Bug: v8:12754
      Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79727}
      173885cd
    • jameslahm's avatar
      [runtime] Check AvailableOptimizedCode in DisassembleFunction · 6693641e
      jameslahm authored
      In DisassembleFunction runtime, function may have available
      optimized code and we could directly set the optimized code
      for the function like in CompileLazy if it's not compiled,
      which avoids calling Compiler::Compile and failed in
      DCHECK(!function->HasAvailableOptimizedCode()).
      
      Bug: v8:12762
      Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79722}
      6693641e