1. 20 May, 2022 1 commit
  2. 04 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      Reland "[osr] Basic support for concurrent OSR" · d187c6c2
      Jakob Gruber authored
      This is a reland of commit 3ce690ee
      
      Changed for the reland:
      - Remove the currently-unused BytecodeArray member to avoid MSAN
        failures.
      - s/return/continue/ in optimizing-compile-dispatcher.
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161
      Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79746}
      d187c6c2
  3. 01 Apr, 2022 1 commit
    • Adam Klein's avatar
      Revert "[osr] Basic support for concurrent OSR" · 32f28553
      Adam Klein authored
      This reverts commit 3ce690ee.
      
      Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188
      
      Original change's description:
      > [osr] Basic support for concurrent OSR
      >
      > This CL adds basic support behind --concurrent-osr,
      > disabled by default.
      >
      > When enabled:
      > 1) the first OSR request starts a concurrent OSR compile job.
      > 2) on completion, the code object is inserted into the OSR cache.
      > 3) the next OSR request picks up the cached code (assuming the request
      >    came from the same JumpLoop bytecode).
      >
      > We add a new osr optimization marker on the feedback vector to
      > track whether an OSR compile is currently in progress.
      >
      > One fundamental issue remains: step 3) above is not guaranteed to
      > hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      > be installed. This will be addressed in a followup by targeting
      > specific bytecode offsets for the install request.
      >
      > This change is based on fanchen.kong@intel.com's earlier
      > change crrev.com/c/3369361, thank you!
      >
      > Bug: v8:12161
      > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Jakob Linke <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79685}
      
      Bug: v8:12161, chromium:1312188
      Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983
      Auto-Submit: Adam Klein <adamk@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79702}
      32f28553
  4. 31 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      [osr] Basic support for concurrent OSR · 3ce690ee
      Jakob Gruber authored
      This CL adds basic support behind --concurrent-osr,
      disabled by default.
      
      When enabled:
      1) the first OSR request starts a concurrent OSR compile job.
      2) on completion, the code object is inserted into the OSR cache.
      3) the next OSR request picks up the cached code (assuming the request
         came from the same JumpLoop bytecode).
      
      We add a new osr optimization marker on the feedback vector to
      track whether an OSR compile is currently in progress.
      
      One fundamental issue remains: step 3) above is not guaranteed to
      hit the same JumpLoop, and a mismatch means the OSR'd code cannot
      be installed. This will be addressed in a followup by targeting
      specific bytecode offsets for the install request.
      
      This change is based on fanchen.kong@intel.com's earlier
      change crrev.com/c/3369361, thank you!
      
      Bug: v8:12161
      Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79685}
      3ce690ee
  5. 30 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      Refactor OptimizationMarker and ConcurrencyMode enums · 57d985a5
      Jakob Gruber authored
      .. with readability and simplicity in mind.
      
      - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering'
        also matches 'TieringManager' terminology.
      - Rename the values:
        kNone -> kNone
        kInOptimizationQueue -> kInProgress
        kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous
        kCompileFoo_Concurrent -> kRequestFoo_Concurrent
      - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous.
      - Add predicates to test enum values.
      - Consistent lower case names for accessors on JSFunction and
        FeedbackVector.
      - Instead of having to call HasOptimizationMarker() before using any
        other accessor, simply have optimization_marker() return kNone if
        no feedback vector exists.
      - Drive-by: Enable the Unreachable() in MaybeOptimizeCode()
        unconditionally - this should never happen, there's no reason not
        to protect against this in release builds as well.
      
      Bug: v8:12161
      Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Auto-Submit: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79669}
      57d985a5
  6. 17 Mar, 2022 1 commit
  7. 21 Feb, 2022 2 commits
  8. 13 Jan, 2022 1 commit
  9. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  10. 10 Dec, 2021 2 commits
  11. 08 Dec, 2021 3 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Delete Jobs as BG work · 85877e54
      Leszek Swirski authored
      Deleting / deallocating Jobs, along with everything they own (e.g.
      PersistentHandles), can take a long time, especially if the allocator
      isn't too friendly to deallocating on a different thread than where the
      allocation happened.
      
      Instead, enqueue Jobs for deletion as part of background processing,
      with the hope that they end up being deallocated on the same thread as
      they were allocated, and at the very least taking the deallocation time
      off the main thread. The deletion queue is processed after the pending
      background jobs are all processed, and counts as a single "background
      job" as far as parallelism is concerned.
      
      Bug: chromium:1275157
      Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78307}
      85877e54
    • 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
  12. 03 Dec, 2021 2 commits
    • 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
    • Leszek Swirski's avatar
      [compiler-dispatcher] Opportunistically finalize · b4f8578f
      Leszek Swirski authored
      Finalize other finalizable jobs in FinishNow, up to a time deadline.
      This deadline is set to 1ms for now, because that seems like short
      enough to not get in the way of user interaction but long enough to be
      worth doing here rather than doing another runtime call for the
      subsequent funtions.
      
      Change-Id: I79f0780e9318e97efee03d2d25701009ca7069d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310801
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78227}
      b4f8578f
  13. 02 Dec, 2021 1 commit
  14. 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
  15. 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
  16. 12 Nov, 2021 1 commit
  17. 05 Nov, 2021 1 commit
  18. 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
  19. 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
  20. 01 Nov, 2021 1 commit
  21. 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
  22. 20 Sep, 2021 1 commit
  23. 19 Aug, 2021 1 commit
  24. 16 Aug, 2021 1 commit
  25. 10 Aug, 2021 2 commits
    • Georg Neis's avatar
      Remove an invalid DCHECK · 12d11216
      Georg Neis authored
      Numfuzz runs our tests without the --testing-d8-test-runner flag.
      
      Bug: v8:12068
      Change-Id: I8915a3e13c918009b8dd90fa05f050a89a484883
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085279
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76206}
      12d11216
    • Georg Neis's avatar
      [compiler][test] Give tests control over finalization · 8b87e36e
      Georg Neis authored
      Some tests want to invalidate part of the VM state after an optimization
      has consumed the old state but before the code is installed.
      
      The existing mechanism for this is --block-concurrent-recompilation
      and %UnblockConcurrentRecompilation(). The former suspends optimization
      right after PrepareJob, before the background ExecuteJob phase. The
      intrinsic can then be used to unblock it again.
      
      This was good enough so far because the main "consume" work used to
      happen on the main thread. With concurrent inlining this is no longer
      true and we need something else.
      
      This CL introduces three intrinsics:
      
      %DisableOptimizationFinalization turns off automatic finalization of
      background optimizations.
      
      %FinalizeOptimization() can then be called at an appropriate time to
      manually finalize (and thus install) the code and reenable automatic
      finalization.
      
      In case one wants to perform some action on the main thread after the
      concurrent optimization has finished but before it is finalized, one can
      do so with the help of %WaitForBackgroundOptimization() (see tests).
      
      In a followup CL I'm removing the old mechanism since it now seems
      redundant.
      
      Bug: v8:12041, v8:7790
      Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76190}
      8b87e36e
  26. 06 Aug, 2021 1 commit
  27. 04 Aug, 2021 1 commit
  28. 09 Jun, 2021 1 commit
  29. 02 Jun, 2021 1 commit
  30. 17 May, 2021 1 commit
  31. 15 Apr, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Spawn concurrent jobs for --stress-concurrent-inlining · 75c5d82b
      Jakob Gruber authored
      .. to increase coverage of concurrent inlining, at least in this stress
      mode. The common pattern in mjsunit tests is to call
      `%OptimizeFunctionOnNextCall(f)` for interesting function `f`. This
      explicitly triggers non-concurrent compilation, significantly decreasing
      relevant coverage of concurrent inlining.
      
      This CL recovers coverage by spawning an additional concurrent compile
      job when 1. --stress-concurrent-inlining is enabled, and 2. the
      requested compile mode is non-concurrent. The result of these
      additional jobs is discarded.
      
      Drive-by: Fix two simple uncovered issues.
      
      Bug: v8:7790,v8:11513,v8:11648
      Change-Id: If1e8ca5ba737e3cecdec9e15e4a86b28fe9fb2de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2824440
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73967}
      75c5d82b
  32. 12 Apr, 2021 1 commit
  33. 23 Mar, 2021 1 commit
    • Nico Hartmann's avatar
      Reland "[TurboFan] Move FunctionTemplateInfo to never serialized" · 07db5a65
      Nico Hartmann authored
      This reverts commit c85b7a44.
      
      This reland fixes missing serialization of objects stored in
      CallHandlerInfo::data by adding necessary handling of these objects
      in FunctionTemplateInfoRef::SerializeCallCode when running with
      direct heap access.
      
      Drive-by: Remove declaration of CallHandlerInfoRef::Serialize, which
      did not have a definition.
      
      Original change's description:
      > [TurboFan] Move FunctionTemplateInfo to never serialized
      >
      > This CL moves FunctionTemplateInfo to the list of never serialized
      > objects, allowing direct heap reads. To make this threadsafe, the CL:
      > - adds necessary atomic (relaxed/acquire-release) operations to the
      >   accessors of FunctionTemplateInfo.
      > - changes FunctionTemplateInfoRef::LookupHolderOfExpectedType to be
      >   usable from the background thread (e.g. no handle construction) with
      >   the caveat of skipping optimization in some cases where necessary
      >   JSObjects are not serialized.
      >
      > Drive-by: Add missing serialization of objects possibly reachable
      > through CallHandlerInfo::data.
      >
      > Bug: v8:7790
      > Change-Id: I49cf4f328ecfab368dff9076fde8f5783ead3246
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679687
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73364}
      
      Bug: v8:7790, chromium:1188563
      Change-Id: Ib43f1eaf0592d2565292e86dea5acfc41a58f637
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773807Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73599}
      07db5a65