Skip to content

V
V8
Switch branch/tag
  1. 30 May, 2022 1 commit
  3. 09 May, 2022 1 commit
  5. 07 Apr, 2022 1 commit
    • Jakob Kummerow's avatar
      [wasm] Count direct calls · 9ca0bfef
      Jakob Kummerow authored 
      This adds feedback collection to count the number of executions of
call_direct instructions in Liftoff code. The purpose is better
inlining decisions in Turbofan, which are enabled by having call
count information for all kinds of calls.
The new feature is gated on --wasm-speculative-inlining. While
direct calls don't need to speculate about their target, the whole
feedback collection infrastructure depends on that flag.

Bug: v8:12166
Change-Id: Ie24a988fcea631f370188dc21e60a5fac923dd3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571807Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79846}
      9ca0bfef
  7. 10 Jan, 2022 1 commit
  9. 08 Dec, 2021 1 commit
    • 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
  11. 06 Dec, 2021 1 commit
  13. 16 Nov, 2021 2 commits
  15. 10 Nov, 2021 1 commit
  17. 05 Nov, 2021 1 commit
  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
  21. 01 Nov, 2021 1 commit
  23. 29 Oct, 2021 1 commit
  25. 18 Oct, 2021 3 commits
  27. 13 Oct, 2021 1 commit
  29. 08 Oct, 2021 1 commit
  31. 08 Jul, 2021 3 commits
  33. 24 Jun, 2021 3 commits
  35. 18 Jun, 2021 1 commit
  37. 14 Jun, 2021 1 commit
  39. 18 May, 2021 1 commit
  41. 21 Apr, 2021 1 commit
  43. 22 Mar, 2021 1 commit
  45. 03 Mar, 2021 1 commit
  47. 19 Feb, 2021 1 commit
  49. 17 Feb, 2021 2 commits
  51. 04 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored 
      ... and mark it as never-serialized wrt turbofan serialization.

Until this CL, the JSRegExp type was used as both for plain
user-visible regexp objects, and for internal regexp boilerplate
descriptions. Boilerplates are special: they are never exposed to the
user, they are only referenced from the feedback vector, they are
immutable.

To clarify this distinction, this CL introduces a dedicated struct
type RegExpBoilerplateDescription to hold the regexp boilerplate
description.

This makes Turbofan serialization simpler: boilerplates can be
accessed through direct reads since they are immutable. TF has no
special requirements on JSRegExp objects (it never reads into these
objects) and thus serializing only the references as a JSObjectRef is
fine.

Bug: v8:7790
Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72522}
      e79b841b
  53. 05 Jan, 2021 1 commit
  55. 13 Nov, 2020 1 commit
  57. 11 Nov, 2020 1 commit
  59. 03 Nov, 2020 1 commit
  61. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored 
      This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.

LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).

This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.

Bug: chromium:1011762

Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  63. 04 Mar, 2020 1 commit