1. 16 May, 2022 1 commit
    • Jakob Kummerow's avatar
      Use a std::shared_ptr for CompilationStats · 6e887c93
      Jakob Kummerow authored
      This fixes a flaky crash when running with --turbo-stats or
      --turbo-stats-wasm.
      With dynamic tiering, it can happen that a compilation job is started
      shortly before the program/test/benchmark terminates and the main thread
      goes through its teardown sequence. When such a late job finishes, it
      still wants to report its statistics, which currently crashes due to
      UAF if the CompilationStats object, which is owned by the main thread,
      has already been deleted.
      
      Change-Id: Ie25a97299fdf40ece8f286487063feadcfa2eea9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645410
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80560}
      6e887c93
  2. 31 Mar, 2022 1 commit
    • Manos Koukoutos's avatar
      Reland "[wasm-gc] Implement isorecursive canonicalization" · cfa8d0b3
      Manos Koukoutos authored
      This is a reland of commit e76ad5c6
      
      Changes compared to original:
      - Move invocation of LAZY_INSTANCE_INITIALIZER to a static global
        variable, as some builds were failing with a function-level static.
      - Drive-by: Improve documentation a bit.
      
      Original change's description:
      > [wasm-gc] Implement isorecursive canonicalization
      >
      > This implements isorecursive canonicalization for static types.
      >
      > Not implemented in this CL:
      > - Runtime type canonicalization.
      > - Cross-module signature canonicalization for purposes of call_indirect.
      >
      > Bug: v8:7748
      > Change-Id: I6214f947444eea8d7b15a29b35c94c3d07ddb525
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541925
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79665}
      
      Bug: v8:7748
      Change-Id: I493fba1906491762f7d8bae50108e3e4a743391d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560480Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79692}
      cfa8d0b3
  3. 14 Oct, 2021 1 commit
  4. 13 Oct, 2021 1 commit
  5. 08 Oct, 2021 1 commit
  6. 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
  7. 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
  8. 22 Jun, 2021 1 commit
    • Clemens Backes's avatar
      Reland "[wasm] Provide a global WasmCodeManager" · 4e19455b
      Clemens Backes authored
      This is a reland of 0f90a2aa.
      The issue was inverted destructor order between WasmCodeManager and
      WasmEngine. WasmEngine has to be destructed first, because it contains
      a barrier to ensure that background compile threads finished before
      global state is being destructed.
      
      Original change's description:
      > [wasm] Provide a global WasmCodeManager
      >
      > The WasmCodeManager was part of the WasmEngine so far, but there is only
      > exactly one WasmEngine. Hence we can pull it out, and also remove the
      > pointer in the WasmCodeAllocator.
      >
      > The argument passed from the single constructor call is now inlined in
      > the constructor itself.
      >
      > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just
      > "CommitPageSize()".
      >
      > R=jkummerow@chromium.org
      >
      > Bug: v8:11879
      > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75270}
      
      Bug: v8:11879
      Change-Id: I0eaa2395f5c1e30f3f7303c5f3df70c227b74d3d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975859
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75289}
      4e19455b
  9. 21 Jun, 2021 3 commits
  10. 18 Jun, 2021 1 commit
  11. 28 Apr, 2021 1 commit
  12. 23 Apr, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Abort wrapper compilation on isolate shutdown · 8c3c89b0
      Clemens Backes authored
      JS-to-Wasm wrappers embed heap constants (like the undefined value), and
      those heap values are being accessed during compilation for tracing.
      This is not a data race, since those values are read-only. But if the
      isolate dies while we are compiling those wrappers, we might read from
      the heap after it has been free'd.
      
      Ideally we would not access the isolate or the heap at all during
      compilation, but delaying all tracing until the "finalization" phase is
      not feasible, and removing the heap value printing from tracing would
      significantly regress quality of this tracing.
      
      Hence this CL only fixes the actual issue: That we keep compiling
      wrappers when the isolate is already gone. It does so by introducing an
      {OperationsBarrier} per isolate that is being taken by each thread that
      executes wrapper compilation, and is used for waiting for background
      threads to finish before the isolate shuts down.
      Additionally, we actually cancel all compilation if a module dies (or
      the isolate shuts down) before it finished baseline compilation. In this
      state, the module cannot be shared between isolates yet, so it's safe to
      fully cancel all compilation. This cancellation is not strictly
      necessary, but it will reduce the time we are blocked while waiting for
      wrapper compilation to finish (because no new compilation will start).
      
      R=thibaudm@chromium.org
      CC=manoskouk@chromium.org
      
      Bug: v8:11626, chromium:1200231
      Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74142}
      8c3c89b0
  13. 16 Mar, 2021 1 commit
  14. 12 Feb, 2021 1 commit
  15. 11 Feb, 2021 2 commits
    • Clemens Backes's avatar
      Revert "[wasm] Send a single scriptParsed event per script" · 724b2eb4
      Clemens Backes authored
      This reverts commit b471bc93.
      
      Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL.
      
      Original change's description:
      > [wasm] Send a single scriptParsed event per script
      >
      > If a script was shared between multiple modules (because they used the
      > same wire bytes) it could happen that we still triggered multiple
      > "scriptParsed" events via CDP. This was because
      > {WasmEngine::GetOrCreateScript} did not communicate back whether it
      > used a cached script or whether it created a new one.
      >
      > This CL moves the call to {Debug::OnAfterCompile} (which triggers the
      > "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
      > such that we only call it once per script.
      > Since the engine only holds a weak reference to the script, we would
      > still trigger multiple events if the script is garbage-collected in the
      > meantime. In this case there is no way around this, as the new script
      > would have a new ID, hence we need to emit a new event to make it
      > public to the debugger.
      >
      > R=​thibaudm@chromium.org
      > CC=​bmeurer@chromium.org
      >
      > Bug: chromium:1151211
      > Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      > Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
      > Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72648}
      
      TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org
      
      Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:1151211
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72667}
      724b2eb4
    • Clemens Backes's avatar
      [wasm] Send a single scriptParsed event per script · b471bc93
      Clemens Backes authored
      If a script was shared between multiple modules (because they used the
      same wire bytes) it could happen that we still triggered multiple
      "scriptParsed" events via CDP. This was because
      {WasmEngine::GetOrCreateScript} did not communicate back whether it
      used a cached script or whether it created a new one.
      
      This CL moves the call to {Debug::OnAfterCompile} (which triggers the
      "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
      such that we only call it once per script.
      Since the engine only holds a weak reference to the script, we would
      still trigger multiple events if the script is garbage-collected in the
      meantime. In this case there is no way around this, as the new script
      would have a new ID, hence we need to emit a new event to make it
      public to the debugger.
      
      R=thibaudm@chromium.org
      CC=bmeurer@chromium.org
      
      Bug: chromium:1151211
      Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72648}
      b471bc93
  16. 19 Jan, 2021 1 commit
  17. 10 Dec, 2020 1 commit
  18. 08 Dec, 2020 1 commit
    • Etienne Pierre-doray's avatar
      Reland "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" · fc1d6f35
      Etienne Pierre-doray authored
      This is a reland of 064ee3c8
      
      Issue 1: WasmEngine UAF when CompilationState is destroyed
      asynchronously
      Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508
      in this CL. Use OperationBarrier to keep WasmEngine alive.
      
      Issue 2: In gin, JobTask lifetime is not extended beyond
      JobHandle, thus making CancelAndDetach unusable.
      This is fixed in chromium here:
      https://chromium-review.googlesource.com/c/chromium/src/+/2566724
      
      Original change's description:
      > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
      >
      > Reason for revert: Data race:
      > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
      >
      > It was assume that MockPlatform runs everything on 1 thread. However,
      > MockPlatform::PostJob previously would schedule the job through
      > TestPlatform, which eventually posts concurrent tasks, thus causing
      > data race.
      > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
      > ensures the jobs also run sequentially.
      >
      > Additional change:
      > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
      > it's called in sequence with ScheduleCompileJobForNewUnits
      >
      > Original CL description:
      > To avoid keeping around a list of job handles, CancelAndDetach() is
      > used in CancelCompilation. Dependency on WasmEngine is handled by a
      > barrier that waits on all jobs to finish.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Original-Commit-Position: refs/heads/master@{#71074}
      > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
      > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71459}
      
      TBR=ulan@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: I6175092c97fea0d5f63a97af232e2d54cccea535
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360
      Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71662}
      fc1d6f35
  19. 01 Dec, 2020 1 commit
    • Etienne Pierre-Doray's avatar
      Revert "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" · 393782ef
      Etienne Pierre-Doray authored
      This reverts commit 064ee3c8.
      
      Reason for revert: Causing blink_web_tests to fail on builder "WebKit Linux MSAN"
      https://bugs.chromium.org/p/chromium/issues/detail?id=1153968
      
      Original change's description:
      > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."
      >
      > Reason for revert: Data race:
      > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121
      >
      > It was assume that MockPlatform runs everything on 1 thread. However,
      > MockPlatform::PostJob previously would schedule the job through
      > TestPlatform, which eventually posts concurrent tasks, thus causing
      > data race.
      > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform
      > ensures the jobs also run sequentially.
      >
      > Additional change:
      > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure
      > it's called in sequence with ScheduleCompileJobForNewUnits
      >
      > Original CL description:
      > To avoid keeping around a list of job handles, CancelAndDetach() is
      > used in CancelCompilation. Dependency on WasmEngine is handled by a
      > barrier that waits on all jobs to finish.
      >
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Original-Commit-Position: refs/heads/master@{#71074}
      > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137
      > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71459}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,etiennep@chromium.org
      Bug: chromium:1153968, v8:11209, v8:11210, v8:11212
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I2c8406bea81ee7cf6c5726c2fec50fffdce09611
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566446Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71519}
      393782ef
  20. 27 Nov, 2020 1 commit
  21. 10 Nov, 2020 2 commits
  22. 09 Nov, 2020 1 commit
  23. 06 Oct, 2020 2 commits
  24. 17 Aug, 2020 1 commit
  25. 05 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Switch compilation to Jobs API · 0c837e83
      Clemens Backes authored
      Use the new jobs API for WebAssembly compilation. This avoids having to
      schedule as many background tasks as there are worker threads. Instead
      the one job specifies the maximum concurrency, which changes dynamically
      as new compile jobs become available.
      This also avoids the artificial deadline we used to ensure that other
      tasks get some share of the CPU resources if needed.
      
      Even though this CL moves actual wasm function completely over to the
      Jobs API, other similar tasks (like wrapper compilation) are still using
      the Task API and need to be ported in a follow-up CL.
      Also, we are still using the same priority for baseline compilation and
      tier up. We should split this in a follow-up CL to have two jobs with
      different priorities. This will also allow us to only block on baseline
      compilation where we currently block on both.
      
      R=ahaas@chromium.org
      CC=gab@chromium.org
      
      Bug: chromium:1101340
      Change-Id: I5656697753346e5fdb15d578425cdb949ac6e364
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280100
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69239}
      0c837e83
  26. 04 May, 2020 1 commit
  27. 17 Apr, 2020 1 commit
  28. 16 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up tiering logic · a776ccaa
      Clemens Backes authored
      This cleans up several parts of the tiering logic.
      1) Instead of using the {ExecutionTier} to specify whether we do tier up
         or down, we introduce a new {TieringState} enum and use that
         consistently (also where a {bool} was used before).
      2) When tiering up or tiering down, always recompile all functions. It's
         very unlikely that we can reuse previous code anyway (tiering down is
         cheap enough to just always do it, and when tiering up we need to
         recompile everything anyway).
      3) Remove the {WasmEngine::RecompileAllFunctions} method and inline the
         implementation into callers.
      4) Drive-by: Remove some obsolete comments and fix or extend others.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic765c6760dd97473ccfd469f22a2514695075587
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151355Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67175}
      a776ccaa
  29. 09 Apr, 2020 3 commits
  30. 06 Apr, 2020 3 commits