1. 12 Mar, 2021 2 commits
  2. 11 Mar, 2021 4 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      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@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
    • Clemens Backes's avatar
      [no-wasm][logging] Remove wasm support for logging · 2dbdfcdd
      Clemens Backes authored
      The definition of {wasm::WasmCode} will not be available in no-wasm
      builds, hence avoid any accesses to WasmCode for logging.
      
      Drive-by: Inline enumeration of wasm modules for logging of existing
      code, to avoid another #if.
      
      R=petermarshall@chromium.org, jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I3b78cf90f9ad155b5bea64e0941531aed2d4291a
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739978Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73338}
      2dbdfcdd
  3. 08 Mar, 2021 2 commits
  4. 05 Mar, 2021 3 commits
  5. 03 Mar, 2021 1 commit
    • Seth Brenith's avatar
      Privatize FixedArray-style accessors on ScopeInfo · 3a366c4d
      Seth Brenith authored
      This is a partial reland of https://crrev.com/c/2601880 .
      
      In preparation for ScopeInfo not being a FixedArrayBase, this change
      privatizes the FixedArray-style functions that provide access to
      ScopeInfo fields by index, and moves them from scope-info-inl.h to
      scope-info.cc. Those functions are still used pretty heavily during
      initialization (ScopeInfo::Create, etc.), but at least we can avoid
      presenting them to the rest of the world.
      
      This change also introduces a new length() function in ScopeInfo which
      hides the one inherited from FixedArrayBase and computes the ScopeInfo's
      length based on its flags, so that there are no remaining readers of the
      'length' field.
      
      Change-Id: I609754010723b679e5cf00f386020faaab84c17a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718275
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73151}
      3a366c4d
  6. 02 Mar, 2021 2 commits
  7. 26 Feb, 2021 1 commit
  8. 23 Feb, 2021 1 commit
  9. 22 Feb, 2021 2 commits
  10. 19 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Revert "Remove 'length' field from ScopeInfo" · 6c922e39
      Seth Brenith authored
      This reverts commit f731e13f.
      
      Reason for revert: perf regressions, chromium:1179757
      
      Original change's description:
      > Remove 'length' field from ScopeInfo
      >
      > ScopeInfo has a vestigial 'length' field from when it used to be a
      > FixedArray. This change removes that field, which saves some memory.
      >
      > More specifically:
      >
      > - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
      >   supplied the 'length' field.
      > - Privatize the FixedArray-style functions that provide access to
      >   ScopeInfo fields by index, and move them from scope-info-inl.h to
      >   scope-info.cc. Those functions are still used pretty heavily during
      >   initialization (ScopeInfo::Create, etc.), but at least we can avoid
      >   presenting them to the rest of the world.
      > - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
      >   It maintains the existing behavior of filling the newly-allocated
      >   object with undefined, even though that's not a valid ScopeInfo and
      >   further initialization is required.
      > - Move part of AccessorAssembler::ScriptContextTableLookup into a new
      >   Torque macro, because it used to rely on casting ScopeInfo to
      >   FixedArrayBase.
      > - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
      >   arrays. I think it makes more sense to list them under "(system)" in
      >   the dev tools, like most other V8 internal types.
      >
      > Bug: v8:8952
      > Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72830}
      
      Bug: v8:8952
      Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72855}
      6c922e39
  11. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Remove 'length' field from ScopeInfo · f731e13f
      Seth Brenith authored
      ScopeInfo has a vestigial 'length' field from when it used to be a
      FixedArray. This change removes that field, which saves some memory.
      
      More specifically:
      
      - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
        supplied the 'length' field.
      - Privatize the FixedArray-style functions that provide access to
        ScopeInfo fields by index, and move them from scope-info-inl.h to
        scope-info.cc. Those functions are still used pretty heavily during
        initialization (ScopeInfo::Create, etc.), but at least we can avoid
        presenting them to the rest of the world.
      - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
        It maintains the existing behavior of filling the newly-allocated
        object with undefined, even though that's not a valid ScopeInfo and
        further initialization is required.
      - Move part of AccessorAssembler::ScriptContextTableLookup into a new
        Torque macro, because it used to rely on casting ScopeInfo to
        FixedArrayBase.
      - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
        arrays. I think it makes more sense to list them under "(system)" in
        the dev tools, like most other V8 internal types.
      
      Bug: v8:8952
      Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72830}
      f731e13f
  12. 15 Feb, 2021 3 commits
    • Benedikt Meurer's avatar
      [stack-traces] Cache source position on StackFrameInfos. · 7b07c779
      Benedikt Meurer authored
      Previously we had cached the source position information on
      JSStackFrame (C++) objects and reused that between calls to
      GetLineNumber() and GetColumnNumber(). The refactoring in
      https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8
      effectively removed that cache, while still making things
      faster though.
      
      This CL puts back the caching on the StackFrameInfo objects
      by reusing the `offset` slot to store the computed source
      position (as indicated by a bit in the `flags`). For promise
      combinator async frames, the bit is always set and the
      `offset_or_source_position` slot thus always contains the source
      position (aka the `promise index` in this case). We also
      added a `StackFrameInfo::ComputeLocation()` method to remove the
      last remaining place where we'd peek into the StackFrameInfo from
      outside stack-frame-info.{cc,h}.
      
      Also-By: kimanh@chromium.org
      Bug: chromium:1077657, v8:8742, chromium:1069425
      Change-Id: I59e26a91965617163776e6cc2610b88e6925452c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386
      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@{#72752}
      7b07c779
    • pthier's avatar
      [sparkplug] Remove feedback vector check in verify-heap. · 0b16593d
      pthier authored
      The check was a leftover from a debugging session.
      We don't have a feedback vector even though we have baseline code,
      e.g. when we share baseline code across realms. In this case
      the feedback vector will be allocated upon the first invocation
      of the function.
      
      Bug: chromium:1177217
      Change-Id: Ia5cde35b0f5d746c2ba64d3ca2083acdfaf286bb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695396
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72745}
      0b16593d
    • Benedikt Meurer's avatar
      [inspector] Send type as description for WasmValueObject. · 987a7f4a
      Benedikt Meurer authored
      Also block sending "type" as part of the ObjectPreview, but only send
      the "value" property. The front-end will be updated to display
      WasmValueObject's similar to what we do for wrapper objects (i.e.
      StringWrapper and the like). The matching front-end change is still
      pending.
      
      Also refactor the WasmValueObject to have dedicated constructors for
      the individual types (i32, i64, f32, f64, externref and v128). This
      way we can just reuse the existing logic in descriptionForObject()
      and we also don't need to store the "type" on the object itself (not
      really performance sensitive, but fewer moving parts / things that
      can go wrong).
      
      This also addresses the crash in https://crbug.com/1166077#c16 since
      the WasmValueObject instances now have a proper JSFunction in their
      maps' constructor_or_backpointer slot and are thus able to locate
      their creation context. Note that this doesn't generally address
      https://crbug.com/1166077 itself, but only the WasmValueObject case.
      
      Screenshot: https://imgur.com/kbd3bix.png
      Bug: chromium:1170282, chromium:1071432
      Bug: chromium:1159402, chromium:1166077
      Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574Reviewed-by: 's avatarPhilip Pfaffe <pfaffe@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72736}
      987a7f4a
  13. 12 Feb, 2021 5 commits
    • Ng Zhi An's avatar
      Reland "[wasm-simd][ia32] Implement i64x2 signed compares" · c5fd776d
      Ng Zhi An authored
      This is a reland of a16add80.
      
      The fixes are adding disassembly for pcmpgtq and vpcmpgtq.
      While fixing also noticed a mistake in assembler for pcmpgtq,
      which flipped dst and src.
      Also realized that we don't detect SSE4.2, so adding that in.
      
      PS2 contains these changes.
      
      Original change's description:
      > [wasm-simd][ia32] Implement i64x2 signed compares
      >
      > The code sequence is exactly the same as x64.
      >
      > Bug: v8:11415
      > Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
      > Reviewed-by: Bill Budge <bbudge@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72637}
      
      Bug: v8:11415
      Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72721}
      c5fd776d
    • Georg Neis's avatar
      Reland "[compiler] Directly read PropertyCells" · cf7cba8d
      Georg Neis authored
      This reverts commit 87df0b7e (thus
      relands 42cd9eb7), with fixes for
      the discovered issues.
      
      Original change's description:
      > Revert "[compiler] Directly read PropertyCells"
      >
      > This reverts commit 42cd9eb7.
      >
      > Reason for revert: Clusterfuzz issues, e.g.
      > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      >
      > Original change's description:
      > > [compiler] Directly read PropertyCells
      > >
      > > Main changes:
      > >
      > > - Introduce a new broker data kind kBackgroundSerialized for objects
      > >   that can be serialized in the background (when direct reads are on).
      > >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      > >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > > - Make PropertyCell use that new kind.
      > > - Introduce a bottleneck in runtime code for changes to PropertyCells
      > >   and make sure that a certain protocol is followed that allows
      > >   concurrent reads from the background thread.
      > > - Improve interface of PropertyCell in various ways.
      > >
      > > Bug: v8:7790
      > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#72586}
      >
      > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      >
      > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      > Bug: v8:7790
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72619}
      
      Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
      Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72697}
      cf7cba8d
    • Leszek Swirski's avatar
      [sparkplug] Change Sparkplug to Baseline · c913ef3a
      Leszek Swirski authored
      Currently we sometimes refer to baseline code or the baseline compiler
      by its codename (Sparkplug). The codename is fun, but we should be
      consistent and call things by one name or the other. Following the
      pattern of Ignition stuff being called "interpreter", we call Sparkplug
      "baseline", and leave the codename only in flags and variants.
      
      Bug: v8:11420
      Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72696}
      c913ef3a
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored
      Following up on https://crrev.com/c/2689185, this CL significantly
      simplifies the whole implementation of the stack trace capturing.
      
      Before this CL, capturing any stack trace (for the purpose of the API or
      Error.stack) would roughly work like this:
      
        1. The CaptureStackTrace() function uses the StackFrameIterator to
           walk the system stack. For each native frame it uses the
           FrameSummary abstraction to get all (including potentially inlined)
           frames. For each of those it appends a record consisting of six
           elements to a FrameArray (this holds pointers to the actual
           closures and receivers).
        2. Afterwards the FrameArray is shrinked to the required size, and a
           new FixedArray is allocated, and initialized with new
           StackTraceFrame objects where each holds a reference to the
           FrameArray, the index of the frame, and an initially uninitialized
           StackFrameInfo reference. This new FixedArray is then returned from
           CaptureStackTrace() and either stored on a message object or
           provided to the API as v8::StackTrace.
      
      The new approach removes a lot of the machinery in between and directly
      creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
      These StackFrameInfo objects are directly exposed as v8::StackFrame on
      the public API, and they hold the six fields that were previously stored
      flat in the FrameArray. This not only avoids a lot of copying around of
      data and creation of temporary objects and handles, but most importantly
      unifies and simplifies the stack frame function inside StackFrameInfo,
      so you no longer need to wonder which function / object might be
      responsible for a certain API.
      
      There's still a lot of room for improvement. In particular we currently
      don't cache the source position for a given StackFrameInfo (or
      globally), but rather recompute it every time. This is still very fast,
      significantly faster than the previous approach.
      
      There are some notable (potentially user visible) changes:
      
        - The CallSite#GetPosition() method now consistently returns the
          Wasm module relative bytecode offset for all Wasm frames (previously
          it'd return the function relative bytecode offset for non-asm.js
          Wasm frames).
        - The column and line numbers returned from StackFrameInfo methods are
          consistently 1-based now, instead of sometimes being 0-based (Wasm)
          and sometimes being 1-based (JS and asm.js Wasm). The only
          potentially noticable difference is that for
          CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
          that was wrong and useless anyways.
        - CallSite#GetThis() would sometimes return the_hole, another bug
          flushed out by this CL.
      
      The CL also contains some other not noteworthy drive-by-cleanups.
      
      Fixed: chromium:1057211
      Bug: chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
    • Leszek Swirski's avatar
      [sparkplug] Upstream Sparkplug · c053419e
      Leszek Swirski authored
      Sparkplug is a new baseline, non-optimising second-tier compiler,
      designed to fit in the compiler trade-off space between Ignition and
      TurboProp/TurboFan.
      
      Design doc:
      https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
      
      Bug: v8:11420
      Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72686}
      c053419e
  14. 11 Feb, 2021 2 commits
    • Santiago Aboy Solanes's avatar
      [objects] Delete double field unboxing · 42409a2e
      Santiago Aboy Solanes authored
      Reasons:
       * We disabled it more than a year ago for all configs
       * Not easy to re-enable
       * Not compatible with pointer compression as-is
       * Not compatible with concurrent TP/TF as-is
       * No concrete plans to re-enable it
      
      Also remove Map's layout_descriptor since it was only used for double
      field unboxing.
      
      Bug: v8:11422
      Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72671}
      42409a2e
    • Benedikt Meurer's avatar
      [stack-traces] Remove StackFrameInfo. · 11b6f176
      Benedikt Meurer authored
      For a long time, V8 had two distinct ways to capture and store a stack
      trace, one where we'd just collect and symbolize the information for the
      v8::StackTrace API (script id, name, line and colum information mostly),
      and one where V8 would also memorize the closures, receivers, and
      optionally the parameters of the stack frame, which we use for
      Error.stack and the non-standard CallSite APIs. Those two were often out
      of sync and suffered from various different issues. Eventually they were
      refactored into a single captureStackTrace() bottleneck that would
      produce a FrameArray.
      
      This CL is a logical continuation of the refactorings. It repairs a
      regression where we'd compute the method name (as part of the
      cached StackFrameInfo) even if we don't need them (as is the case for
      the inspector and any other use of the v8::StackTrace API).
      
      Everytime a method was invoked on StackTraceFrame, it'd call into
      StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
      like this:
      
        1. Create a FrameArrayIterator and point it to the FrameArray at the
           index stored in the StackTraceFrame.
        2. Invoke FrameArrayIterator::Frame(), which copies the information
           from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
           or WasmStackFrame C++ object, and use the StackFrameBase virtual
           methods to transfer all information to a newly created
           StackFrameInfo object.
        3. Kill the link to the FrameArray and put a link to the
           StackFrameInfo object into the StackTraceFrame.
      
      This caching turned out to be extremely costly, since beyond other
      things, it'd always invoke JSStackFrame::GetMethodName(), which is
      extremely costly (the execution time is linear in the number of
      properties on the receiver and it's prototype chain). The cost was so
      high that several work-arounds had been added, which would avoid
      triggering the eager construction of the StackFrameInfo object (i.e.
      https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
      https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).
      
      This CL removes the StackFrameInfo caching completely, since neither the
      inspector nor Error.stack benefit from the caching at all. It's only the
      first part in a series of refactorings that will significantly reduce
      the complexity and overhead of the stack trace collection.
      
      Doc: https://bit.ly/2wkbuIy
      Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72647}
      11b6f176
  15. 10 Feb, 2021 3 commits
    • Daniel Clark's avatar
      Fix top-level await crash from synthetic module being evaluated twice · f033e2a1
      Daniel Clark authored
      With top-level await, when Evaluate is performed on an already-evaluated
      synthetic module, Module::InnerEvaluate returns undefined.  This breaks
      top-level await's assumption that the returned value is always a
      promise.
      
      In order to make SyntheticModule's behavior consistent with
      SourceTextModule, the top_level_capability field is moved up to Module
      and SyntheticModule::Evaluate places the promise returned from the
      host's evaluation steps in that field.  Now SourceTextModule and
      SyntheticModule can share the same code to handle the case where the
      module is either kErrored or kEvaluated, so the code for this
      is moved up to Module.
      
      Thus, SyntheticModule is now guaranteed to return the
      promise from the evaluation steps even on subsequent Evaluate() calls.
      
      Unfortunately Node hasn't yet updated their EvaluationStepsCallback
      to return a Promise, so we can't yet assume that the returned value
      is a Promise without breaking Node.  So, this change also adds a clause
      to check for this condition and create a new resolved Promise if one
      was not provided by the callback steps.  This could eventually be
      removed once Node's callback steps are updated for top-level await.
      
      Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
      Bug: v8:11398
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72629}
      f033e2a1
    • Seth Brenith's avatar
      Don't use floating-point values in basic block instrumentation · a66f2b00
      Seth Brenith authored
      Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573
      I updated BasicBlockInstrumentor to use 64-bit floating-point values
      rather than 32-bit integers, so that it could never overflow. However,
      I've now learned that some builtins (particularly RecordWrite) are not
      allowed to use floating-point registers, and so running with
      basic block instrumentation enabled could produce incorrect results.
      This change switches back to 32-bit integers, but adds saturation logic.
      
      Bug: chromium:1170776
      Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72626}
      a66f2b00
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored
      This reverts commit 42cd9eb7.
      
      Reason for revert: Clusterfuzz issues, e.g.
      https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      
      Original change's description:
      > [compiler] Directly read PropertyCells
      >
      > Main changes:
      >
      > - Introduce a new broker data kind kBackgroundSerialized for objects
      >   that can be serialized in the background (when direct reads are on).
      >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > - Make PropertyCell use that new kind.
      > - Introduce a bottleneck in runtime code for changes to PropertyCells
      >   and make sure that a certain protocol is followed that allows
      >   concurrent reads from the background thread.
      > - Improve interface of PropertyCell in various ways.
      >
      > Bug: v8:7790
      > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72586}
      
      TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      
      Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  16. 09 Feb, 2021 5 commits
  17. 04 Feb, 2021 2 commits
    • Ng Zhi An's avatar
      [wasm-simd][ia32] Implement double precision conversions · fec9c5d6
      Ng Zhi An authored
      Implement these 6 instructions:
      
      - f64x2.convert_low_i32x4_s
      - f64x2.convert_low_i32x4_u
      - i32x4.trunc_sat_f64x2_s_zero
      - i32x4.trunc_sat_f64x2_u_zero
      - f32x4.demote_f64x2_zero
      - f64x2.promote_low_f32x4
      
      The code sequences are exactly the same as on x64.
      
      Needed to add some more instructions, and we don't have macro lists for
      these instructions yet, so individually define them for now. We can
      factor them into lists in a future change.
      
      Bug: v8:11265
      Change-Id: I606e1226201e3c5ecdc7e3f611315437e917d77c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668913Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72535}
      fec9c5d6
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored
      ... and mark it as never-serialized wrt turbofan serialization.
      
      Until this CL, the JSRegExp type was used as both for plain
      user-visible regexp objects, and for internal regexp boilerplate
      descriptions. Boilerplates are special: they are never exposed to the
      user, they are only referenced from the feedback vector, they are
      immutable.
      
      To clarify this distinction, this CL introduces a dedicated struct
      type RegExpBoilerplateDescription to hold the regexp boilerplate
      description.
      
      This makes Turbofan serialization simpler: boilerplates can be
      accessed through direct reads since they are immutable. TF has no
      special requirements on JSRegExp objects (it never reads into these
      objects) and thus serializing only the references as a JSObjectRef is
      fine.
      
      Bug: v8:7790
      Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72522}
      e79b841b