1. 03 May, 2021 1 commit
  2. 20 Apr, 2021 1 commit
    • Maya Lekova's avatar
      Reland "[fastcall] Add support for leaf interface type checks" · 5540fbfc
      Maya Lekova authored
      This is a reland of 6124a534
      
      It fixes a UAF issue in the d8 test by moving the test API object
      constructor to PerIsolateData. It also fixes a crash in Chromium
      caused by current usage of v8::ApiObject, which should be migrated
      to v8::Value*.
      
      Original change's description:
      > [fastcall] Add support for leaf interface type checks
      >
      > This CL adds an IsTemplateForApiObject method to FunctionTemplate
      > allowing the embedder to check whether a given API object was
      > instantiated by this template without including parent templates
      > in the search. It also replaces the v8::ApiObject in the fast API
      > with a raw v8::Value pointer to allow use of standard C++ casts.
      >
      > Bug: chromium:1052746
      > Change-Id: I0812ec8b4daaa5f5005aabf10b63e1e84e0b8f03
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595310
      > Commit-Queue: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73999}
      
      Bug: chromium:1052746, chromium:1199900
      Change-Id: I4b7f0c9e9152919dde4a1d0c48fbf5ac8c5b13d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835711Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74064}
      5540fbfc
  3. 16 Apr, 2021 2 commits
  4. 24 Mar, 2021 1 commit
  5. 23 Mar, 2021 1 commit
    • Maya Lekova's avatar
      Revert "Reland [dict-proto] C++ implementation of SwissNameDictionary, pt. 10" · 5e8417a2
      Maya Lekova authored
      This reverts commit bb2ca416.
      
      Reason for revert: WrapAround test is timing out on TSAN and closing the tree, please check https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36014/overview.
      
      Original change's description:
      > Reland [dict-proto] C++ implementation of SwissNameDictionary, pt. 10
      >
      > This is a reland of
      > https://chromium-review.googlesource.com/c/v8/v8/+/2744138. It
      > shortens the runtime of the Copy and EnumerationOrder tests in
      > cctest/test-swiss-name-dictionary-csa for TSAN and CFI builds, as
      > compared to the original version.
      >
      > Original description:
      >
      > This CL is part of a series that adds the C++ implementation of
      > SwissNameDictionary, a deterministic property backing store based on
      > Swiss Tables.
      >
      > This CL adds the actual tests for SwissNameDictionary, defined in
      > test-swiss-name-dictionary-shared-tests.h, using the infrastructure
      > in test-swiss-name-dictionary-infra.[h|cc].
      >
      > Bug: v8:11388
      > Change-Id: Ia3f83f6e27be80bfdd63c2cb868638dc90d24cbc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778416
      > Commit-Queue: Frank Emrich <emrich@google.com>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73589}
      
      Bug: v8:11388
      Change-Id: Ib95a7183cf9de35a33ec641bc1ec38915c3711c8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780294
      Auto-Submit: Maya Lekova <mslekova@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@{#73593}
      5e8417a2
  6. 22 Mar, 2021 3 commits
  7. 05 Feb, 2021 1 commit
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored
      This is a reland of 6ada6a90
      
      - Fixed a GC issue
        https://bugs.chromium.org/p/v8/issues/detail?id=11335:
        GC expected all arguments on the stack from code with
        CodeKind::TURBOFAN to be tagged objects. This is not the case now with
        inlined Wasm calls, and this information can be passed in
        SafepointEntry for each call site.
      
      - Disabled JS-to-Wasm inlining for calls inside try/catch.
      
      For more details, see updated doc:
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      
      Bug: v8:11092
      
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests).
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
      > generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  8. 22 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Revert "Reland "Faster JS-to-Wasm calls"" · 51ecfaec
      Paolo Severini authored
      This reverts commit 6ada6a90.
      
      Reason for revert: Revert for link issue:
      https://bugs.chromium.org/p/v8/issues/detail?id=11335
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests)
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      >
      >
      > Original change's description:
      > > Faster JS-to-Wasm calls
      > >
      > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      > >
      > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > > the basis of the signature of a Wasm function to call, and whose task
      > > is to:
      > > - set "thread_in_wasm_flag" to true
      > > - convert the arguments from tagged types into Wasm native types
      > > - calculate the address of the Wasm function to call and call it
      > > - convert back the result from Wasm native types into tagged types
      > > - reset "thread_in_wasm_flag" to false.
      > >
      > > This CL tries to improve the performance of JS-to-Wasm calls by
      > > inlining the code of the JS-to-Wasm wrappers in the call site.
      > >
      > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > > this kind of calls. A 'JSWasmCall' node is associated to
      > > WasmCallParameters, which contain information about the signature of
      > > the Wasm function to call.
      > >
      > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > > of the Wasm function, when the conversion is not necessary.
      > > The actual inlining of the graph generated for this wrapper happens in
      > > the simplified-lowering phase.
      > >
      > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > > lazy deoptimizations that can happen if the Wasm function callee calls
      > > back some JS code that invalidates the compiled JS caller function.
      > >
      > > Bug: v8:11092
      > > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > > Cr-Commit-Position: refs/heads/master@{#71824}
      >
      > Bug: v8:11092
      > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72147}
      
      Tbr: ahaas@chromium.org, jgruber@chromium.org
      Bug: v8:11092, v8:11335
      Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72253}
      51ecfaec
  9. 19 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Reland "Faster JS-to-Wasm calls" · 6ada6a90
      Paolo Severini authored
      This is a reland of 860fcb1b
      
      - Disabled the tests for this feature in V8-lite mode (the original
      change broke V8-lite tests)
      - Also modified test console-profile-wasm.js that was brittle with this
      change because it assumed that there was always a JS-to-Wasm wrapper
      but this is not the case when the TurboFan compilation completes before
      the Liftoff-compiled code starts to run.
      
      More changes in Patchset 8:
      
      - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      into a new phase, wasm-inlining that reuses the JSInliner reducer.
      The doc
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      describes the new logic.
      
      - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      this should solve the problem we had inlining the calls in functions
      that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72147}
      6ada6a90
  10. 14 Jan, 2021 1 commit
  11. 17 Dec, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "Faster JS-to-Wasm calls" · de50785e
      Nico Hartmann authored
      This reverts commit 860fcb1b.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
      
      Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:11092
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71825}
      de50785e
    • Paolo Severini's avatar
      Faster JS-to-Wasm calls · 860fcb1b
      Paolo Severini authored
      This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      
      Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      the basis of the signature of a Wasm function to call, and whose task
      is to:
      - set "thread_in_wasm_flag" to true
      - convert the arguments from tagged types into Wasm native types
      - calculate the address of the Wasm function to call and call it
      - convert back the result from Wasm native types into tagged types
      - reset "thread_in_wasm_flag" to false.
      
      This CL tries to improve the performance of JS-to-Wasm calls by
      inlining the code of the JS-to-Wasm wrappers in the call site.
      
      It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      this kind of calls. A 'JSWasmCall' node is associated to
      WasmCallParameters, which contain information about the signature of
      the Wasm function to call.
      
      WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      of the Wasm function, when the conversion is not necessary.
      The actual inlining of the graph generated for this wrapper happens in
      the simplified-lowering phase.
      
      A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      lazy deoptimizations that can happen if the Wasm function callee calls
      back some JS code that invalidates the compiled JS caller function.
      
      Bug: v8:11092
      Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis (ooo until January 5) <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71824}
      860fcb1b
  12. 26 Nov, 2020 1 commit
  13. 24 Nov, 2020 1 commit
  14. 18 Nov, 2020 1 commit
  15. 10 Nov, 2020 1 commit
  16. 16 Sep, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · 76217f57
      Alex Kodat authored
      While the sampler checked if the sampled thread had the Isolate locked
      (if locks are being used) under Linux, the check was not done under
      Windows (or Fuchsia) which meant that in a multi-threading application
      under Windows, thread locking was not checked making it prone to seg
      faults and the like as the profiler would be using isolate->js_entry_sp
      to determine the stack to walk but isolate->js_entry_sp is the stack
      pointer for the thread that currently has the Isolate lock so, if the
      sampled thread does not have the lock, the sampler woud be iterating
      over the wrong stack, one that might actually be actively changing on
      another thread. The fix was to move the lock check into CpuSampler
      and Ticker (--prof) so all OSes would do the correct check.
      
      The basic concept is that on all operating systems a CpuProfiler, and
      so its corresponding CpuCampler, the profiler is tied to a thread.
      This is not based on first principles or anything, it's simply the
      way it works in V8, though it is a useful conceit as it makes
      visualization and interpretation of profile data much easier.
      
      To collect a sample on a thread associated with a profiler the thread
      must be stopped for obvious reasons -- walking the stack of a running
      thread is a formula for disaster. The mechanism for stopping a thread
      is OS-specific and is done in sample.cc. There are currently three
      basic approaches, one for Linux/Unix variants, one for Windows and one
      for Fuchsia. The approaches vary as to which thread actually collects
      the sample -- under Linux the sample is actually collected on the
      (interrupted) sampled thread whereas under Fuchsia/Windows it's on
      a separate thread.
      
      However, in a multi-threaded environment (where Locker is used), it's
      not sufficient for the sampled thread to be stopped. Because the stack
      walk involves looking in the Isolate heap, no other thread can be
      messing with the heap while the sample is collected. The only ways to
      ensure this would be to either stop all threads whenever collecting a
      sample, or to ensure that the thread being sampled holds the Isolate
      lock so prevents other threads from messing with the heap. While there
      might be something to be said for the "stop all threads" approach, the
      current approach in V8 is to only stop the sampled thread so, if in a
      multi-threaded environment, the profiler must check if the thread being
      sampled holds the Isolate lock.
      
      Since this check must be done, independent of which thread the sample
      is being collected on (since it varies from OS to OS), the approach is
      to save the thread id of the thread to be profiled/sampled when the
      CpuSampler is instantiated (on all OSes it is instantiated on the
      sampled thread) and then check that thread id against the Isolate lock
      holder thread id before collecting a sample. If it matches, we know
      sample.cc has stop the sampled thread, one way or another, and we know
      that no other thread can mess with the heap (since the stopped thread
      holds the Isolate lock) so it's safe to walk the stack and collect data
      from the heap so the sample can be taken. It it doesn't match, we can't
      safely collect the sample so we don't.
      
      Bug: v8:10850
      Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69952}
      76217f57
  17. 03 Sep, 2020 2 commits
  18. 01 Sep, 2020 1 commit
    • Peter Marshall's avatar
      Revert "[cpu-profiler] Ensure sampled thread has Isolate lock under Windows" · 32435062
      Peter Marshall authored
      This reverts commit dfb3f7da.
      
      Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861
      
      Original change's description:
      > [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
      > 
      > While the sampler checked if the sampled thread had the Isolate locked
      > (if locks are being used) under Linux, the check was not done under
      > Windows (or Fuchsia) which meant that in a multi-threading application
      > under Windows, thread locking was not checked making it prone to seg
      > faults and the like as the profiler would be extracting info from a
      > heap in motion. The fix was to move the lock check into CpuSampler
      > and Ticker (--prof) so all OSes would do the correct check.
      > 
      > The basic concept is that on all operating systems a CpuProfiler, and
      > so its corresponding CpuCampler, the profiler is tied to a thread.
      > This is not based on first principles or anything, it's simply the
      > way it works in V8, though it is a useful conceit as it makes
      > visualization and interpretation of profile data much easier.
      > 
      > To collect a sample on a thread associated with a profiler the thread
      > must be stopped for obvious reasons -- walking the stack of a running
      > thread is a formula for disaster. The mechanism for stopping a thread
      > is OS-specific and is done in sample.cc. There are currently three
      > basic approaches, one for Linux/Unix variants, one for Windows and one
      > for Fuchsia. The approaches vary as to which thread actually collects
      > the sample -- under Linux the sample is actually collected on the
      > (interrupted) sampled thread whereas under Fuchsia/Windows it's on
      > a separate thread.
      > 
      > However, in a multi-threaded environment (where Locker is used), it's
      > not sufficient for the sampled thread to be stopped. Because the stack
      > walk involves looking in the Isolate heap, no other thread can be
      > messing with the heap while the sample is collected. The only ways to
      > ensure this would be to either stop all threads whenever collecting a
      > sample, or to ensure that the thread being sampled holds the Isolate
      > lock so prevents other threads from messing with the heap. While there
      > might be something to be said for the "stop all threads" approach, the
      > current approach in V8 is to only stop the sampled thread so, if in a
      > multi-threaded environment, the profiler must check if the thread being
      > sampled holds the Isolate lock.
      > 
      > Since this check must be done, independent of which thread the sample
      > is being collected on (since it varies from OS to OS), the approach is
      > to save the thread id of the thread to be profiled/sampled when the
      > CpuSampler is instantiated (on all OSes it is instantiated on the
      > sampled thread) and then check that thread id against the Isolate lock
      > holder thread id before collecting a sample. If it matches, we know
      > sample.cc has stop the sampled thread, one way or another, and we know
      > that no other thread can mess with the heap (since the stopped thread
      > holds the Isolate lock) so it's safe to walk the stack and collect data
      > from the heap so the sample can be taken. It it doesn't match, we can't
      > safely collect the sample so we don't.
      > 
      > Bug: v8:10850
      > Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69623}
      
      TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com
      
      Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10850
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69638}
      32435062
  19. 31 Aug, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · dfb3f7da
      Alex Kodat authored
      While the sampler checked if the sampled thread had the Isolate locked
      (if locks are being used) under Linux, the check was not done under
      Windows (or Fuchsia) which meant that in a multi-threading application
      under Windows, thread locking was not checked making it prone to seg
      faults and the like as the profiler would be extracting info from a
      heap in motion. The fix was to move the lock check into CpuSampler
      and Ticker (--prof) so all OSes would do the correct check.
      
      The basic concept is that on all operating systems a CpuProfiler, and
      so its corresponding CpuCampler, the profiler is tied to a thread.
      This is not based on first principles or anything, it's simply the
      way it works in V8, though it is a useful conceit as it makes
      visualization and interpretation of profile data much easier.
      
      To collect a sample on a thread associated with a profiler the thread
      must be stopped for obvious reasons -- walking the stack of a running
      thread is a formula for disaster. The mechanism for stopping a thread
      is OS-specific and is done in sample.cc. There are currently three
      basic approaches, one for Linux/Unix variants, one for Windows and one
      for Fuchsia. The approaches vary as to which thread actually collects
      the sample -- under Linux the sample is actually collected on the
      (interrupted) sampled thread whereas under Fuchsia/Windows it's on
      a separate thread.
      
      However, in a multi-threaded environment (where Locker is used), it's
      not sufficient for the sampled thread to be stopped. Because the stack
      walk involves looking in the Isolate heap, no other thread can be
      messing with the heap while the sample is collected. The only ways to
      ensure this would be to either stop all threads whenever collecting a
      sample, or to ensure that the thread being sampled holds the Isolate
      lock so prevents other threads from messing with the heap. While there
      might be something to be said for the "stop all threads" approach, the
      current approach in V8 is to only stop the sampled thread so, if in a
      multi-threaded environment, the profiler must check if the thread being
      sampled holds the Isolate lock.
      
      Since this check must be done, independent of which thread the sample
      is being collected on (since it varies from OS to OS), the approach is
      to save the thread id of the thread to be profiled/sampled when the
      CpuSampler is instantiated (on all OSes it is instantiated on the
      sampled thread) and then check that thread id against the Isolate lock
      holder thread id before collecting a sample. If it matches, we know
      sample.cc has stop the sampled thread, one way or another, and we know
      that no other thread can mess with the heap (since the stopped thread
      holds the Isolate lock) so it's safe to walk the stack and collect data
      from the heap so the sample can be taken. It it doesn't match, we can't
      safely collect the sample so we don't.
      
      Bug: v8:10850
      Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69623}
      dfb3f7da
  20. 28 Aug, 2020 1 commit
  21. 26 Aug, 2020 1 commit
  22. 24 Jul, 2020 1 commit
  23. 23 Jul, 2020 1 commit
  24. 26 May, 2020 1 commit
  25. 24 Apr, 2020 1 commit
  26. 09 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [api] Create v8::String::NewFromLiteral that returns Local<String> · b097a8e5
      Dan Elphick authored
      String::NewFromLiteral is a templated function that takes a char[N]
      argument that can be used as an alternative to String::NewFromUtf8 and
      returns a Local<String> rather than a MaybeLocal<String> reducing the
      number of ToLocalChecked() or other checks.
      
      Since the string length is known at compile time, it can statically
      assert that the length is less than String::kMaxLength, which means that
      it can never fail at runtime.
      
      This also converts all found uses of NewFromUtf8 taking a string literal
      or a variable initialized from a string literal to use the new API. In
      some cases the types of stored string literals are changed from const
      char* to const char[] to ensure the size is retained.
      
      This API does introduce a small difference compared to NewFromUtf8. For
      a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
      would treat this as a 3 character string, whereas the new API will treat
      it as a 7 character string.
      
      As a drive-by fix, this also fixes all redundant uses of
      v8::NewStringType::kNormal when passed to any of the String::New*
      functions.
      
      Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66622}
      b097a8e5
  27. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored
      This is a reland of 137bfe47
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      Bug: v8:10026
      Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  28. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored
      This reverts commit 137bfe47.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072
      
      Original change's description:
      > [arm64] Protect return addresses stored on stack
      > 
      > This change uses the Arm v8.3 pointer authentication instructions in
      > order to protect return addresses stored on the stack.  The generated
      > code signs the return address before storing on the stack and
      > authenticates it after loading it. This also changes the stack frame
      > iterator in order to authenticate stored return addresses and re-sign
      > them when needed, as well as the deoptimizer in order to sign saved
      > return addresses when creating new frames. This offers a level of
      > protection against ROP attacks.
      > 
      > This functionality is enabled with the v8_control_flow_integrity flag
      > that this CL introduces.
      > 
      > The code size effect of this change is small for Octane (up to 2% in
      > some cases but mostly much lower) and negligible for larger benchmarks,
      > however code size measurements are rather noisy. The performance impact
      > on current cores (where the instructions are NOPs) is single digit,
      > around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      > cores than for little cores.
      > 
      > Bug: v8:10026
      > Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66239}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored
      This change uses the Arm v8.3 pointer authentication instructions in
      order to protect return addresses stored on the stack.  The generated
      code signs the return address before storing on the stack and
      authenticates it after loading it. This also changes the stack frame
      iterator in order to authenticate stored return addresses and re-sign
      them when needed, as well as the deoptimizer in order to sign saved
      return addresses when creating new frames. This offers a level of
      protection against ROP attacks.
      
      This functionality is enabled with the v8_control_flow_integrity flag
      that this CL introduces.
      
      The code size effect of this change is small for Octane (up to 2% in
      some cases but mostly much lower) and negligible for larger benchmarks,
      however code size measurements are rather noisy. The performance impact
      on current cores (where the instructions are NOPs) is single digit,
      around 1-2% for ARES-6 and Octane, and tends to be smaller for big
      cores than for little cores.
      
      Bug: v8:10026
      Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  29. 08 Jan, 2020 1 commit
  30. 29 Nov, 2019 1 commit
    • Sigurd Schneider's avatar
      [cctest] Check compilation result in v8_compile · 88f8d801
      Sigurd Schneider authored
      This CL introduces a CHECK in v8_compile that compilation succeedes.
      Previously, a failed compilation would lead to undefined behavior or
      a crash in CompileRun, because it would call Script::Run on a nullptr.
      This CL introduced v8_try_compile that returns a MaybeLocal and supports
      test-cases that want to ensure that a compilation fails.
      
      Bug: chromium:1014415
      Change-Id: I559190da6049f325e8650e4a29c6e387d8ff7af5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943154
      Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65266}
      88f8d801
  31. 26 Nov, 2019 1 commit
  32. 28 May, 2019 1 commit
  33. 24 May, 2019 1 commit
  34. 23 May, 2019 1 commit