1. 09 Dec, 2021 1 commit
  2. 07 Dec, 2021 1 commit
    • Clemens Backes's avatar
      [counters] Make all counters thread-safe · f0c982b8
      Clemens Backes authored
      D8 shares counters across isolates, so even if they are only updated
      from the main thread, they need to be thread-safe.
      This CL removes the distinction between {StatsCounter} and
      {StatsCounterThreadSafe}, and just makes all {StatsCounter} use (cheap)
      atomic operations for counter updates. This will make previously
      thread-safe counters cheaper, because no Mutex is involved. It might
      make previously not-thread-safe counters slightly more expensive, but
      it's not expected to be a significant regression.
      
      R=mlippautz@chromium.org
      
      Bug: v8:12481, v8:12482
      Change-Id: I47b8681c1cf26d142e1ccfafa0c192e3fdcb7d2a
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320427Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78278}
      f0c982b8
  3. 29 Nov, 2021 1 commit
  4. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  5. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  6. 09 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      Reland "[counters] Fix reentrant timers for V8.Execute" · f688fe08
      Camillo Bruni authored
      This is a reland of fffcbaea
      
      Additional fixes:
      - Relax IsStarted DCHECKs in ElapsedTimer for paused_elapsed
      - Add LogEventStatus enum in the API for better testing
      - Rename Logger::StartEnd enum values to kXXX
      - Add additional NestedTimedHistogramScope tests
      
      Original change's description:
      > [counters] Fix reentrant timers for V8.Execute
      >
      > This CL fixes a long standing issue where reentering TimedHistograms
      > scopes would cause spurious measurements. Only the non-nested scopes
      > yielded correct results.
      >
      > Due to the changed numbers, the V8.Execute histogram is renamed to
      > V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      > behind the --slow-histograms flag due to the additional overhead.
      >
      > Unlike before, it does no longer include time for external callbacks
      > and only measures self time. The following example illustrates the
      > new behaviour:
      >
      > 1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      > 2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      > 3. Re-enter V8:             |---|      self-time: 3 units (reported)
      >
      > This would result in 2 histogram entries with 4 time units for the first
      > V8 slice and 3 units for the nested part. Note that the callback time
      > itself is ignored.
      >
      > This CL attempts to clean up how TimedHistograms work:
      > - Histogram: the base class
      > - TimedHistograms: used for time-related histograms that are not nested
      > - NestedTimeHistograms: Extends TimedHistograms and is used for nested
      >   histograms
      >
      > This CL changes Histograms to not measure time themselves. Measurements
      > happen in the *HistogramScopes:
      > - BaseTimedHistogramScope: Base functionality
      > - TimedHistogramScope: For non-nested measurements
      > - NestedTimedHistogramScope: For nested measurements
      > - PauseNestedTimedHistogramScope: Ignore time during a given scope.
      >   This is used to pause timers during callbacks.
      >
      > Additional changes:
      > - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
      >   and always sets VMState<EXTERNAL>
      >
      > Bug: v8:11946
      > Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#76111}
      
      Bug: v8:11946
      Change-Id: Ic2eef7456fbc245febcf780b23418f6ab0bebdb7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080566
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76180}
      f688fe08
  7. 06 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      Revert "[counters] Fix reentrant timers for V8.Execute" · a12c6fa2
      Leszek Swirski authored
      This reverts commit fffcbaea.
      
      Reason for revert: Breaks in Chromium (e.g. https://ci.chromium.org/p/v8/builders/ci/Linux%20V8%20FYI%20Release%20%28NVIDIA%29)
      
      Original change's description:
      > [counters] Fix reentrant timers for V8.Execute
      >
      > This CL fixes a long standing issue where reentering TimedHistograms
      > scopes would cause spurious measurements. Only the non-nested scopes
      > yielded correct results.
      >
      > Due to the changed numbers, the V8.Execute histogram is renamed to
      > V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      > behind the --slow-histograms flag due to the additional overhead.
      >
      > Unlike before, it does no longer include time for external callbacks
      > and only measures self time. The following example illustrates the
      > new behaviour:
      >
      > 1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      > 2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      > 3. Re-enter V8:             |---|      self-time: 3 units (reported)
      >
      > This would result in 2 histogram entries with 4 time units for the first
      > V8 slice and 3 units for the nested part. Note that the callback time
      > itself is ignored.
      >
      > This CL attempts to clean up how TimedHistograms work:
      > - Histogram: the base class
      > - TimedHistograms: used for time-related histograms that are not nested
      > - NestedTimeHistograms: Extends TimedHistograms and is used for nested
      >   histograms
      >
      > This CL changes Histograms to not measure time themselves. Measurements
      > happen in the *HistogramScopes:
      > - BaseTimedHistogramScope: Base functionality
      > - TimedHistogramScope: For non-nested measurements
      > - NestedTimedHistogramScope: For nested measurements
      > - PauseNestedTimedHistogramScope: Ignore time during a given scope.
      >   This is used to pause timers during callbacks.
      >
      > Additional changes:
      > - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
      >   and always sets VMState<EXTERNAL>
      >
      > Bug: v8:11946
      > Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#76111}
      
      Bug: v8:11946
      Change-Id: I954de1afbabf101fb5d4f52eca0d3b80a723385b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077153
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76138}
      a12c6fa2
  8. 05 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      [counters] Fix reentrant timers for V8.Execute · fffcbaea
      Camillo Bruni authored
      This CL fixes a long standing issue where reentering TimedHistograms
      scopes would cause spurious measurements. Only the non-nested scopes
      yielded correct results.
      
      Due to the changed numbers, the V8.Execute histogram is renamed to
      V8.ExecuteMicroSeconds. Note that this histogram is also guarded
      behind the --slow-histograms flag due to the additional overhead.
      
      Unlike before, it does no longer include time for external callbacks
      and only measures self time. The following example illustrates the
      new behaviour:
      
      1. Enter V8:           |--+.......+--| self-time: 4 units (reported)
      2. Exit V8 (callback):    |-+...+-|    self-time: 2 units (ignored)
      3. Re-enter V8:             |---|      self-time: 3 units (reported)
      
      This would result in 2 histogram entries with 4 time units for the first
      V8 slice and 3 units for the nested part. Note that the callback time
      itself is ignored.
      
      This CL attempts to clean up how TimedHistograms work:
      - Histogram: the base class
      - TimedHistograms: used for time-related histograms that are not nested
      - NestedTimeHistograms: Extends TimedHistograms and is used for nested
        histograms
      
      This CL changes Histograms to not measure time themselves. Measurements
      happen in the *HistogramScopes:
      - BaseTimedHistogramScope: Base functionality
      - TimedHistogramScope: For non-nested measurements
      - NestedTimedHistogramScope: For nested measurements
      - PauseNestedTimedHistogramScope: Ignore time during a given scope.
        This is used to pause timers during callbacks.
      
      Additional changes:
      - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
        and always sets VMState<EXTERNAL>
      
      Bug: v8:11946
      Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76111}
      fffcbaea
  9. 02 Aug, 2021 1 commit
    • Camillo Bruni's avatar
      [counters] Add --slow-histograms flag · fd3d44f6
      Camillo Bruni authored
      The V8.Execute histogram is not free and can cause more overhead
      than expected. This CL is guarding slower histograms behind a new
      --slow-histograms flag.
      
      For now --slow-histograms is enabled by default. Once all
      chrome-side changes and benchmark changes have landed it will be
      disabled by default.
      
      --dump-counters will automatically enable --slow-histograms.
      
      The goal is to not report slow histograms on UMA by default on stable:
      - 100% reporting on canary/dev/beta
      - 1% reporting on stable or specific finch experiments
      
      Chrome-side feature: https://crrev.com/c/3065464
      
      Bug: v8:11946
      Change-Id: I23c782288e10ceb76323d72eceea9170739fd543
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067318
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76041}
      fd3d44f6
  10. 09 Jun, 2021 1 commit
  11. 12 Apr, 2021 1 commit
  12. 29 Mar, 2021 1 commit
  13. 08 Mar, 2021 1 commit
  14. 24 Feb, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm][turbofan] Implement loop unrolling for wasm · 40ebe845
      Manos Koukoutos authored
      Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/
      
      Currently, wasm loop unrolling is disabled by default. We intend to
      further investigate its compilation time cost and running time benefits
      before enabling it.
      
      Additional changes:
      - Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight
        loop analysis.
      - Move EliminateLoopExit into LoopPeeling and expose it.
      - Introduce loop_info_ field into WasmGraphBuildingInterface, fill it
        up in Loop().
      - Break after encountering the first loop in BuildNestedLoopExits.
      - Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated
        in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction
        to be filled up by WasmGraphBuildingInterface, and then passed to
        GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase.
      - Introduce WasmLoopUnrollingPhase and insert it into the wasm
        compilation pipeline.
      - Fix an issue where exception values were not wrapped in
        WasmGraphBuilderInterface.
      - Update --wasm-loop-unrolling flag description.
      
      Bug: v8:11298
      Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73009}
      40ebe845
  15. 12 Feb, 2021 1 commit
  16. 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
  17. 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
  18. 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
  19. 07 Jan, 2021 2 commits
  20. 26 Nov, 2020 1 commit
  21. 25 Nov, 2020 1 commit
  22. 19 Nov, 2020 1 commit
  23. 05 Nov, 2020 1 commit
    • Devlin Cronin's avatar
      Introduce Function::FunctionProtoToString() · 2ccd4dc5
      Devlin Cronin authored
      Add a new function on the public API to allow serializing a function to
      a string using the built-in toString() implementation, allowing
      serialization without worrying about untrusted author script overriding
      the toString() implementation. This is similar in nature to
      Object::ObjectProtoToString() (but that only returns "[object Function]"
      for any passed function).
      
      Add tests for the same.
      
      Bug: chromium:1144841
      Change-Id: Ie4c29b870034c0817c23bf91f9424f956098823d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2514768Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70976}
      2ccd4dc5
  24. 04 Nov, 2020 1 commit
  25. 28 Oct, 2020 1 commit
  26. 27 Oct, 2020 1 commit
  27. 22 Oct, 2020 1 commit
  28. 28 Sep, 2020 1 commit
  29. 08 Sep, 2020 1 commit
  30. 04 Aug, 2020 1 commit
  31. 28 Jul, 2020 2 commits
    • Ross McIlroy's avatar
      [TurboProp] Add reference map population to fast reg alloc. · e9a37bf8
      Ross McIlroy authored
      Adds support for populating reference maps to the fast
      register allocator. In order to calculate whether a stack slot
      is live at a given instruction, we use the dominator tree to
      build a bitmap of blocks which are dominated by each block.
      A variable's spill operand is classed as alive for any blocks that are
      dominated by the block it was defined in, until the instruction index
      of the spill operand's last use. As such, it may be classified as live
      down a branch where the spill operand is never used, however it is safe
      since the spill slot won't be re-allocated until after it's last-use
      instruction index in any case.
      
      BUG=v8:9684
      
      Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69108}
      e9a37bf8
    • Ross McIlroy's avatar
      [TurboProp] Add support for spill slot allocation to fast reg alloc · 5b0c6cde
      Ross McIlroy authored
      Adds support for tracking the instruction range of spilled operands,
      and then allocating spill slots to these ranges. It also adds some
      unittests covering spill slot allocation.
      
      Spill slots are allocated in a linear fashion, running through the
      instruction stream in a linear order, ensuring that no spill operand
      is allocated to a same spill slot that is already assigned to during
      this whole start / end range. This isn’t optimal, since it doesn’t
      take into account holes in these ranges (e.g, blocks between start
      and end that aren’t dominated by the start), but in practice rarely
      leads to more than one extra spill slot being allocated compared to
      the current allocator.
      
      BUG=v8:9684
      
      Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69107}
      5b0c6cde
  32. 22 Jul, 2020 1 commit
  33. 10 Jul, 2020 1 commit
  34. 03 Jun, 2020 1 commit
  35. 30 Apr, 2020 1 commit
  36. 08 Apr, 2020 1 commit
  37. 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