Skip to content

V
V8
Switch branch/tag
  1. 28 Jun, 2022 1 commit
  3. 14 Jun, 2022 1 commit
  5. 30 May, 2022 1 commit
  7. 21 Apr, 2022 1 commit
  9. 14 Apr, 2022 1 commit
  11. 08 Apr, 2022 1 commit
  13. 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
  15. 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
  17. 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
  19. 17 Mar, 2022 1 commit
  21. 02 Mar, 2022 1 commit
  23. 24 Feb, 2022 1 commit
  25. 21 Feb, 2022 2 commits
  27. 27 Jan, 2022 1 commit
  29. 17 Jan, 2022 1 commit
  31. 16 Dec, 2021 1 commit
  33. 10 Dec, 2021 1 commit
  35. 08 Dec, 2021 3 commits
    • Leszek Swirski's avatar
      [compiler] Use SmallVector for Parser->BG thread use counts · ffdc50a9
      Leszek Swirski authored 
      Change the off-thread parse to fill a SmallVector<UseCounterFeature, 8>
on the BG compile task, rather than an int[kUseCounterFeatureCount]
array. This allows us to keep the loop over use counts in the compile
task finalization short by avoiding looping over unused counters.

The value 8 was chosen as a "reasonable small number"; experimenting on
our benchmarks shows a max of 3 use counts collected per compile (and
at a vanishingly low percentage of all compiles).

Passing around an explicit SmallVector<UseCounterFeature, 8> pointer,
complete with size, is a bit ugly, but since it's used only in this one
place (Parser -> BackgroundCompileTask) I can live with it to avoid
further indirections. Typedeffing it is possible, but it's not clear
where, since it's needed in both src/codegen/compiler.h and
src/parsing/parser.h, and neither includes the other.

Change-Id: Idb73e2f56fa9e8911ea29fb810d7562246f19d46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318662Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78305}
      ffdc50a9
    • 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
  37. 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
  39. 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
  41. 12 Nov, 2021 1 commit
  43. 05 Nov, 2021 1 commit
  45. 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
  47. 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
  49. 01 Nov, 2021 1 commit
  51. 29 Oct, 2021 1 commit
  53. 28 Oct, 2021 1 commit
  55. 27 Oct, 2021 1 commit
  57. 14 Oct, 2021 1 commit
  59. 12 Oct, 2021 1 commit
  61. 24 Aug, 2021 2 commits
  63. 17 Aug, 2021 1 commit
  65. 09 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [api] Add API for off-thread code cache deserialization · f888f48e
      Leszek Swirski authored 
      To consume a code cache off-thread

  1. The embedder creates a CachedData object wrapping the data blob.
  2. The embedder calls ScriptCompiler::StartConsumingCodeCache with the
     CachedData, and receives a ScriptCompiler::CodeCacheConsumeTask
     which takes ownership of the CachedData.
  3. The embedder calls ScriptCompiler::CodeCacheConsumeTask::Run
     on a different thread.
  4. Once this completes, the embedded passes the completed task as an
     optional argument into Source constructor, and calls Compile as
     before.

This is roughly similar to how streaming compilation works, with the
QoL improvement that Source owns the CodeCacheConsumeTask and therefore
we can reuse the same Compile method and do the off-thread finalization
behind the scenes inside Compile.

On the v8::internal side, ScriptCompiler::CodeCacheConsumeTask wraps a
v8::internal::BackgroundDeserializeTask, which has a Run and a Finish
method. The Run creates a LocalIsolate (again, similar to
BackgroundCompileTask), calls some helpers on CodeSerializer, and stores
the pre-finalization result in a OffThreadDeserializeData structure.
This stores Persistent Handles to the off-thread initialized SFI and
a vector of Scripts needing fixing up, and it owns the PersistentHandles
object which owns those Handles. Finally, the Finish method consumes
this OffThreadDeserializeData structure, fixes up Scripts, moves the
SFI Handle into the caller HandleScope, and that's it.

Since we don't yet have the source at off-thread deserialization time,
the various code cache sanity checks are done without the source hash
when deserializing, and the Finish method re-does them now that the
source is available.

Bug: chromium:1075999
Change-Id: If1faf35ba3ef840fa4e735581d0b29c96c1d5fc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067322
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76155}
      f888f48e
  67. 04 Aug, 2021 2 commits
  69. 02 Jun, 2021 1 commit