1. 01 Nov, 2021 1 commit
  2. 29 Oct, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Port to Jobs API · 15b1ce39
      Leszek Swirski authored
      Port the CompilerDispatcher to use the Jobs API, instead of its own
      hand-rolled worker management.
      
      This required some re-thinking of how testing is handled, since the
      tests want to be able to
      
        a) Defer calls to PostTask/Job, to actuall post the jobs later. This
           was easy enough with PostTask, since we could simply store the task
           in a list and no-op, but PostJob has to return a JobHandle. The
           tests now have a DelayedJobHandleWrapper, which defers all method
           calls on itself, and because of all the unique_ptrs, there's also
           now a SharedJobHandleWrapper.
      
        b) Wait until tasks/jobs complete. Returning from a Task meant that
           the task had completed, but this isn't necessarily the case with
           JobTasks; e.g. a job might be asked to yield. This patch hacks
           around this by Posting and Joining a non-owning copy of the
           requested JobTask, and then re-posting it once Join returns.
      
      Change-Id: If867b4122af52758ffabcfb78a6701f0f95d896d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563664
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77618}
      15b1ce39
    • Leszek Swirski's avatar
      [off-thread] Allow off-thread top-level IIFE finalization · 35a6eeec
      Leszek Swirski authored
      Allow off-thread finalization for parallel compile tasks (i.e. for top-
      level IIFEs).
      
      This allows us to merge the code paths in BackgroundCompileTask, and
      re-enable the compiler dispatcher tests under the off-thread
      finalization flag. Indeed, we can simplify further and get rid of that
      flag entirely (it has been on-by-default for several releases now).
      
      Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77615}
      35a6eeec
  3. 06 Aug, 2021 1 commit
  4. 16 Feb, 2021 1 commit
  5. 19 Nov, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce LocalIsolate for main thread" · dc45361e
      Dominik Inführ authored
      This is a reland of e95e1b62
      
      After landing https://crrev.com/c/2546682, this CL can be relanded
      without changes.
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      Bug: v8:10315
      Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656
      TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71274}
      dc45361e
  6. 17 Nov, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "[heap] Introduce LocalIsolate for main thread" · 9235f258
      Michael Achenbach authored
      This reverts commit e95e1b62.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71228}
      9235f258
    • Dominik Inführ's avatar
      [heap] Introduce LocalIsolate for main thread · e95e1b62
      Dominik Inführ authored
      Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      kept alive during the whole lifetime of the Isolate. The main thread
      LocalIsolate starts in the Running state in contrast to the background
      thread LocalIsolates (those start in Parked).
      
      Code paths in Turbofan that used to create a LocalIsolate on the main
      thread can now simply use the main thread LocalIsolate.
      
      LocalIsolate for the main thread will help in reducing differences
      between the main and background threads. The goal is that the main
      thread behaves more like a background thread.
      
      The main thread LocalIsolate should also make it simpler to share code
      between main thread and background threads by using LocalIsolate for
      both.
      
      Bug: v8:10315
      Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71226}
      e95e1b62
  7. 16 Nov, 2020 1 commit
  8. 06 Nov, 2020 1 commit
  9. 28 Oct, 2020 1 commit
  10. 16 Oct, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[compiler, heap] Create LocalHeap outside of ExecuteJob" · de914c75
      Dominik Inführ authored
      This is a reland of 44708a5b
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      Bug: v8:10315
      Change-Id: I4c459fd6dfb98d47fc9941c0dc6864bf5a1d2d3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474788Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70560}
      de914c75
  11. 15 Oct, 2020 2 commits
    • Georg Neis's avatar
      Revert "[compiler, heap] Create LocalHeap outside of ExecuteJob" · 04c85d7c
      Georg Neis authored
      This reverts commit 44708a5b.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70522}
      04c85d7c
    • Dominik Inführ's avatar
      [compiler, heap] Create LocalHeap outside of ExecuteJob · 44708a5b
      Dominik Inführ authored
      Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      pass its reference as argument to ExecuteJob. This allows us to create
      LocalHeap differently for the main and background thread, e.g. by
      passing an additional argument to the constructor in the future.
      It will be required in the future anyways when the main thread will
      have its own LocalHeap/LocalIsolate.
      
      Extending the scope of LocalHeap, also made
      HandleBase::IsDereferenceAllowed more precise and uncovered two
      potential issues: heap accesses in
      OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      with --code-comments.
      
      LocalHeap can now be created in the parked state. Also fixed a data
      race with LocalHeap's destructor publishing write barrier entries
      without holding the lock.
      
      Bug: v8:10315
      Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70521}
      44708a5b
  12. 30 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      Rename legacy code kinds · 29bcdaad
      Jakob Gruber authored
      CodeKind::OPTIMIZED_CODE -> TURBOFAN
      
      Kinds are now more fine-grained and distinguish between TF, TP, NCI.
      
      CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING
      
      Code stubs (like builtins, but generated at runtime) were removed from
      the codebase years ago, this is the last remnant. This kind is used
      only for deopt entries (which should be converted into builtins) and
      for tests.
      
      Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70234}
      29bcdaad
  13. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  14. 10 Jul, 2020 1 commit
  15. 15 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add native_context_independent flags · f30b53bd
      Jakob Gruber authored
      ... to OptimizedCompilationInfo, BytecodeGraphBuilder, and
      JSHeapBroker.
      
      Also add first uses of these flags in pipeline.cc by skipping certain
      phases when nci is enabled. With this change, tests in the NCI variant
      will start to fail since generic lowering is not fully implemented.
      These implementations will follow incrementally in the next days.
      
      Bug: v8:8888
      Change-Id: I3f570fb92f09059d1f1f4015f88ffe80ccf746ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239572
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68339}
      f30b53bd
  16. 24 Apr, 2020 1 commit
  17. 23 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored
      Move the persistent compilation state and Isolate inputs (such as the
      allocator, shared AST constants, hash seed, logger, etc.) which survives
      across both parse and compile, out of ParseInfo and into a new
      UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
      for per-thread state such as stack limit and RCS.
      
      In particular, this new state survives the ParseInfo being destructed,
      which means it is available after off-thread finalization. This allows a
      followup to access the PendingCompilationErrorHandler after finalization
      and report errors on merge.
      
      Bug: v8:10314
      Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
  18. 24 Jan, 2020 1 commit
  19. 08 Jan, 2020 1 commit
  20. 27 Nov, 2019 1 commit
  21. 10 Sep, 2019 1 commit
  22. 23 Aug, 2019 1 commit
  23. 29 Jul, 2019 1 commit
  24. 21 Jun, 2019 1 commit
    • Ross McIlroy's avatar
      [SFI] Always store function_literal_id in SFI. · f92d7196
      Ross McIlroy authored
      Calling FindIndexInScript performs a linear search on the script functions and can
      take considerable time. With Bytecode flushing we will lose the function_literal_id
      and have to call FindIndexInScript if we ever recompile the flushed function. This
      can take a significant proportion of the recompilation time and has caused regressions
      in rendering times for some web applications (e.g, 395ms in FindIndexInScript for 132ms
      spent lazily re-compiling code).
      
      To avoid this, add function_literal_id back into the SFI and remove it from
      UnoptimizedCompileInfo. This will slightly regress memory usage (particularly
      in cases where many of the SFIs are compiled), however it means we can remove
      the FindIndexInScript function and avoid these long-tail regressions when
      bytecode is flushed.
      
      BUG=chromium:965833
      
      Change-Id: Ia31e82eb6c871a6d698a518326a8555822a7a1d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669700Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62319}
      f92d7196
  25. 04 Jun, 2019 1 commit
    • Leszek Swirski's avatar
      [tracing] Speed up SharedFunctionInfo::TraceID · 43cd5d10
      Leszek Swirski authored
      Avoid the linear lookup of function literal id when getting the shared
      function info TraceID, by optionally passing through a FunctionLiteral.
      Additionally, use the FunctionLiteralId helper when a FunctionLiteral is
      not available, since it can also fast-path in some cases.
      
      As a drive-by, allow using a ScriptIterator without an Isolate pointer
      (e.g. manually creating a handle) to allow calling FunctionLiteralId
      without an Isolate pointer.
      
      Bug: v8:9325
      Change-Id: Ibfa053f300d6d5005485c67174a848264a5d1372
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643429
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61983}
      43cd5d10
  26. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  27. 24 May, 2019 1 commit
  28. 23 May, 2019 2 commits
  29. 22 May, 2019 1 commit
  30. 21 May, 2019 1 commit
  31. 17 May, 2019 1 commit
  32. 16 May, 2019 2 commits
  33. 08 Mar, 2019 1 commit
  34. 15 Feb, 2019 1 commit
  35. 13 Feb, 2019 1 commit