1. 08 Jul, 2021 2 commits
    • Patrick Thier's avatar
      Reland "Reland "Reland "Improve error messages for property access on null/undefined""" · c0fd89c3
      Patrick Thier authored
      This is a reland of 819c3ae2
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75645}
      c0fd89c3
    • Leszek Swirski's avatar
      Revert "Reland "Reland "Improve error messages for property access on null/undefined""" · 7ac7b72b
      Leszek Swirski authored
      This reverts commit 819c3ae2.
      
      Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352
      Auto-Submit: Leszek Swirski <leszeks@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@{#75626}
      7ac7b72b
  2. 07 Jul, 2021 1 commit
    • Patrick Thier's avatar
      Reland "Reland "Improve error messages for property access on null/undefined"" · 819c3ae2
      Patrick Thier authored
      This is a reland of 8b18c5e6
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75604}
      819c3ae2
  3. 06 Jul, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "Reland "Improve error messages for property access on null/undefined"" · 94cd8b64
      Leszek Swirski authored
      This reverts commit 8b18c5e6.
      
      Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217
      Auto-Submit: Leszek Swirski <leszeks@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@{#75577}
      94cd8b64
    • Patrick Thier's avatar
      Reland "Improve error messages for property access on null/undefined" · 8b18c5e6
      Patrick Thier authored
      This is a reland of 24c626c1
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75571}
      8b18c5e6
  4. 21 Jun, 2021 1 commit
    • Bill Budge's avatar
      Revert "Improve error messages for property access on null/undefined" · b261213f
      Bill Budge authored
      This reverts commit 24c626c1.
      
      Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail):
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109?
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75282}
      b261213f
  5. 18 Jun, 2021 2 commits
  6. 09 Jun, 2021 1 commit
  7. 12 Apr, 2021 1 commit
  8. 08 Apr, 2021 1 commit
  9. 11 Mar, 2021 3 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
  10. 16 Feb, 2021 1 commit
  11. 12 Feb, 2021 1 commit
    • 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
  12. 09 Feb, 2021 1 commit
  13. 05 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Speed up method name inference. · 57062d6c
      Benedikt Meurer authored
      In JSStackFrame::GetMethodName() we try to infer a useful method name to
      show for the closure to which the stack frame belongs. This is done by
      first considering the functions name, and checking if the receiver has a
      property with that name and if that property's value is the closure. In
      case the function doesn't have a name or the property's value is not the
      closure itself, we fall back to a reverse lookup of the closure within
      the object (and its prototypes).
      
      This CL speeds up this logic by attacking two problems:
      
      1. The reverse lookup was performed by first using the KeyAccumulator to
         extract the names of all enumerable properties, and afterwards using
         the LookupIterator on each name, and testing the resulting property
         value against the closure. This is fairly slow and creates a lot of
         temporary objects and handles. We now look into the descriptor arrays
         or dictionary backing stores of the objects directly instead, which
         is easily 2-10x faster.
      2. For the common case of `o.foo = function() { ... }` the parser already
         places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
         which we can use as a hint to infer the name of the function instead
         of immediately falling back to the expensive reverse lookup.
      
      This repairs the regression reported in http://crbug.com/1069425 and
      recovers most of the slowdown reported in http://crbug.com/1077657
      (there's still some overhead left from the async stack trace tracking).
      
      Fixed: chromium:1069425
      Bug: chromium:1077657
      Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72545}
      57062d6c
  14. 01 Dec, 2020 1 commit
  15. 26 Nov, 2020 1 commit
  16. 23 Nov, 2020 3 commits
  17. 24 Oct, 2020 1 commit
    • Camillo Bruni's avatar
      Reland "[runtime] Use Isolate::ThrowAt with MessageLocation" · 447915ef
      Camillo Bruni authored
      This is a reland of eb6b4ce1
      
      Skip test that serializes Error which references a Script. All errors
      created by ThrowAt store the current Script under the
      error_script_symbol.
      
      Original change's description:
      > [runtime] Use Isolate::ThrowAt with MessageLocation
      >
      > Fix various missing source positions when reporting parse and compile
      > errors. Namely this fixes missing source positions when having invalid
      > module imports.
      >
      > - Use Isolate::ThrowAt with valid MessageLocation objects
      > - Change public Isolate::Throw to no longer accept MessageLocation to
      >   avoid misues
      > - Introduce private Isolate::ThrowInternal that accepts MessageLocation
      >
      > Bug: v8:6513
      > Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70623}
      
      Bug: v8:6513
      Change-Id: Icba74f74178e28fbda0fd0c237eeb7bacbc33570
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487123Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70741}
      447915ef
  18. 19 Oct, 2020 2 commits
  19. 30 Sep, 2020 1 commit
  20. 10 Jun, 2020 1 commit
  21. 29 May, 2020 1 commit
  22. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored
      This reverts commit 4e5fabae.
      
      Reason for revert: performance regressions chromium:1085305, chromium:1084978
      
      Original change's description:
      > [torque][cleanup] Use more precise field types in a few classes
      > 
      > This change updates some Torque-defined classes to include more precise
      > field types where possible. It also updates those classes to use
      > @generateCppClass. One field was removed because it's unused
      > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
      > actually became less precise because they're based on Script::name,
      > which is an embedder-provided untyped Local<Value>. (Automatically
      > generated accessors pointed out this bug easily.)
      > 
      > This change also includes a couple of minor fixes in Torque.
      > 
      > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67907}
      
      TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  23. 19 May, 2020 1 commit
  24. 13 May, 2020 1 commit
  25. 11 May, 2020 1 commit
  26. 06 May, 2020 1 commit
  27. 30 Apr, 2020 1 commit
  28. 24 Apr, 2020 1 commit
  29. 23 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored
      Move the persistent compilation state and Isolate inputs (such as the
      allocator, shared AST constants, hash seed, logger, etc.) which survives
      across both parse and compile, out of ParseInfo and into a new
      UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
      for per-thread state such as stack limit and RCS.
      
      In particular, this new state survives the ParseInfo being destructed,
      which means it is available after off-thread finalization. This allows a
      followup to access the PendingCompilationErrorHandler after finalization
      and report errors on merge.
      
      Bug: v8:10314
      Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
  30. 22 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^5 "[parser] Introduce UnoptimizedCompileFlags" · a3228bfc
      Leszek Swirski authored
      This is a reland of e1b93a4f
      which was a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Give up on using C++ bitfields, go back to having base::BitField and
      getters/setters.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org
      
      Bug: v8:10314
      Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67309}
      a3228bfc
  31. 21 Apr, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "Reland^4 "[parser] Introduce UnoptimizedCompileFlags"" · 33ea5e55
      Leszek Swirski authored
      This reverts commit e1b93a4f.
      
      Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274
      
      Original change's description:
      > Reland^4 "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of 313d4844
      > which was a reland of 0a59e0cb
      > which was a reland of 146f5375
      > which was a reland of d91679bf
      > 
      > Manually zero out flags with memset, since GCC appears not to initialize
      > the bitfield values to zero even with a default constructor.
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      > 
      > Bug: v8:10314
      > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67271}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67275}
      33ea5e55
    • Leszek Swirski's avatar
      Reland^4 "[parser] Introduce UnoptimizedCompileFlags" · e1b93a4f
      Leszek Swirski authored
      This is a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Manually zero out flags with memset, since GCC appears not to initialize
      the bitfield values to zero even with a default constructor.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      
      Bug: v8:10314
      Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67271}
      e1b93a4f