1. 06 Apr, 2022 1 commit
    • Leszek Swirski's avatar
      [test] Add a unittest platform setup mixin · 0ff82052
      Leszek Swirski authored
      Change the unittest runner to no longer uncondtionally set up a default
      platform in the "environment", but to instead make platform set-up part
      of the "mixin" framework for test fixtures.
      
      Requires modifying some tests that expect the platform to be available,
      and all flag implications resolved, before the mixin constructors run.
      
      We still keep the environment for setting up the process for cppgc. This
      process setup can only be done once per process, so it can no longer use
      the platform -- that's ok though, the page allocator used by cppgc's
      process initialisation doesn't have to be the same as the platform's so
      we can just pass in a separate new one.
      
      Change-Id: Ic8ccf39722e8212962c5bba87350c4b304388a7c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571886Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79820}
      0ff82052
  2. 17 Mar, 2022 1 commit
  3. 08 Dec, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move Job pointer to SFI · 3b9091c8
      Leszek Swirski authored
      Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
      the sets and hashmaps, and instead:
      
        1. Turning the pending job set into a queue, and
        2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
           the LazyCompilerDispatcher::Job, instead of maintaining an
           IdentityMap from one to the other.
      
      To avoid bloating all UncompiledData, this adds two new UncompiledData
      subclasses, making it four subclasses total, for with/without Preparse
      data and with/without a Job pointer. "should_parallel_compile"
      FunctionLiterals get allocated an UncompiledData with a job pointer by
      default, otherwise enqueueing a SFI without a job pointer triggers a
      reallocation of the UncompiledData to add a job pointer.
      
      Since there is no longer a set of all Jobs (aside from one for
      debug-only), we need to be careful to manually clear the Job pointer
      from the UncompiledData whenever we finish a Job (whether successfully
      or by aborting) and we have to make sure that we implicitly can reach
      all Jobs via the pending/finalizable lists, or the set of currently
      running jobs.
      
      Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78302}
      3b9091c8
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
      which stores a couple of pointers and most importantly the Zone and
      AstValueFactory of the parse. This allows the Zone and AstValueFactory
      to be reused across multiple parses, rather than re-initialising
      per-Parse.
      
      With this, we can amend the LazyCompileDispatcher to initialise one
      LocalIsolate, Zone and AstValueFactory per background thread loop,
      rather than one per compile task, which allows us to reduce per-task
      costs and re-use the AstValueFactory's string table and previous String
      internalizations.
      
      Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
  4. 03 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Create ParseInfo on BG thread · a66c7a38
      Leszek Swirski authored
      Rather than creating a ParseInfo when creating a BackgroundCompileTask
      (and passing ownership across to the BG thread which deallocates it),
      create one when running it.
      
      This allows the ParseInfo Zone to be both allocated and deallocated on
      the same thread, which will improve its allocator friendliness.
      
      As a side-effect, we now use the on-heap PreparseData from the
      SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
      means that we don't have to copy the PreparseData across Zones, but we
      do need to Unpark the LocalHeap when accessing preparse data.
      
      Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78228}
      a66c7a38
  5. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  6. 15 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Post compile tasks from ignition instead of the parser · 6b2fa4c1
      Leszek Swirski authored
      Posting compile tasks from the parser has several issues:
      
        1. We don't know how many functions there will be total, so we can't
           yet allocate shared_function_infos array on the Script
        2. Without this array, inner function compiles can't look up their own
           inner functions during bytecode finalization, so we can't run that
           finalization before script parse completes
        3. Scope analysis can't have run yet, so we can only post top-level
           function tasks and if we allocate SharedFunctionInfos early they
           are forced into a bit of a limbo state without an outer ScopeInfo.
      
      Instead, we can post compile tasks during bytecode generation. Then, the
      script parse is guaranteed to have completed, so we'll have a
      shared_function_infos array and we will have allocated ScopeInfos
      already. This also opens the door for posting tasks for compiling more
      inner functions than just top-level, as well as generating better code
      for functions/methods that reference same-script top-level
      let/const/class.
      
      Bug: chromium:1267680
      Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77894}
      6b2fa4c1
  7. 12 Nov, 2021 1 commit
  8. 05 Nov, 2021 1 commit
  9. 04 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
      the canonical id for these jobs.
      
      This has several consequences:
      
        * We no longer split enqueing a job and registering a SFI with that
          job. We did this previously because we could not allocate SFIs in
          the Parser -- now with LocalHeap we can, so we do.
        * We remove the separate Job vector, and make the SFI IdentityMap
          hold pointers to Jobs directly. This requires a small amount of
          extra care to deallocate Jobs when removing them from the map,
          but it means not having to allocate new global handles for jobs.
        * The SFI is passed into the BackgroundCompileTask instead of the
          script, so our task finalization doesn't need the SFI anymore.
        * We no longer need to iterate ParallelTasks after compiling (to
          register SFIs), so we can get rid of ParallelTasks entirely and
          access the dispatcher directly from the parser.
      
      There are a few drive-bys since we're touching this code:
      
        * Jobs are move to have a "state" variable rather than a collection
          of bools, for stricter DCHECKing.
        * There's no longer a set of "currently running" jobs, since this
          was only used to check if a job is running, we can instead inspect
          the job's state directly.
        * s/LazyCompilerDispatcher/LazyCompileDispatcher/g
      
      Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
  10. 03 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[off-thread] Allow off-thread top-level IIFE finalization" · 548c40ed
      Leszek Swirski authored
      This is a reland of 35a6eeec
      
      Reland fixes:
        * Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI
          from the placeholder. This now includes copying scope_info (which
          wasn't included in the original CL and caused some of the issues)
        * Make sure that LocalHandleScope is initialised only inside of
          UnparkedScope (fixed TSAN issues)
        * Clean-up: Don't add `script_` to ParseInfo, but instead pass it
          separately to Parser. Eventually we'd ideally get rid of ParseInfo
          entirely (splitting it into input and output) so let's not add more
          fields to it. Reverts changing CreateScript to InitializeScript.
      
      Original change's description:
      > [off-thread] Allow off-thread top-level IIFE finalization
      >
      > 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/+/3226780
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77615}
      
      Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77676}
      548c40ed
  11. 01 Nov, 2021 1 commit
  12. 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
  13. 06 Aug, 2021 1 commit
  14. 16 Feb, 2021 1 commit
  15. 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
  16. 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
  17. 16 Nov, 2020 1 commit
  18. 06 Nov, 2020 1 commit
  19. 28 Oct, 2020 1 commit
  20. 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
  21. 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
  22. 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
  23. 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
  24. 10 Jul, 2020 1 commit
  25. 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
  26. 24 Apr, 2020 1 commit
  27. 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
  28. 24 Jan, 2020 1 commit
  29. 08 Jan, 2020 1 commit
  30. 27 Nov, 2019 1 commit
  31. 10 Sep, 2019 1 commit
  32. 23 Aug, 2019 1 commit
  33. 29 Jul, 2019 1 commit
  34. 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
  35. 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
  36. 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