1. 09 May, 2022 1 commit
  2. 26 Apr, 2022 1 commit
    • Patrick Thier's avatar
      Reland "[string] Non-transitioning shared strings" · fa1caae9
      Patrick Thier authored
      This is a reland of commit 8ba60b7a
      
      Changes to original:
      - Weaken DCHECK in MakeThin to allow direct transitions of shared
        strings during deserialization. This is safe as the string to be
        transitioned is freshly created and hasn't escaped the thread yet.
        - To enable this, add has_active_deserializer() to LocalIsolate
      
      - Shared thin string transitions are subject to the same layout changes
        as non-shared thin string transitions, thus treat them equally when
        checking if a map transition is safe.
      
      Original change's description:
      > [string] Non-transitioning shared strings
      >
      > Instead of transitioning shared strings to ThinString on
      > internalization, use a forwarding table to the internalized string and
      > store the index into the forwarding table in the string's hash field.
      >
      > This way we don't need to handle concurrent string transitions that
      > modify the underlying string data.
      >
      > During stop-the-world GC, live strings in the forwarding table are
      > migrated to regular ThinStrings.
      >
      > Bug: v8:12007
      > Change-Id: I6c6f3d41c6f644e0aaeafbf25ecec5ce0aa0d2d8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536647
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79801}
      
      Bug: v8:12007
      Change-Id: I022e5c4768b763a86bb28c9c82218c3b807371a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571817Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80183}
      fa1caae9
  3. 19 Apr, 2022 1 commit
  4. 10 Dec, 2021 1 commit
  5. 08 Dec, 2021 1 commit
    • 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
  6. 17 Nov, 2021 1 commit
    • Tobias Tebbi's avatar
      [builtins] add Torque fast-path for String.prototype.localeCompare · 6181ce59
      Tobias Tebbi authored
      This fast path works for ASCII-only strings and is similar to the
      existing fast-path in C++. Important differences:
      - The locale check is done at Turbofan optimization time instead of
        at runtime
      - Use tables of size 256 instead of 128 to save a bounds-check when
        handling one-byte strings.
      - It first performs an equality check that's optimized for detecting
        inequality quickly by comparing the strings from both ends. If the
        equality check succeeds, we are done. Otherwise chances are high
        that the strings differ according to collation level L1 already.
        Therefore, we first do an L1 check and perform the L3 check
        only when L1 didn't find a difference. This is based on the assumption
        that few strings are identical except for different capitalization.
      - Use the Torque version of string flattening instead of the runtime
        version.
      
      Bug: v8:12196
      Change-Id: I2d043c1138846783f6d567b736d34063ba9301e5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268465Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77946}
      6181ce59
  7. 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
  8. 18 Oct, 2021 3 commits
  9. 27 Sep, 2021 1 commit
  10. 10 Aug, 2021 1 commit
  11. 30 Jul, 2021 1 commit
  12. 26 Jul, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[offthread] Template deserializer on Isolate" · 6f898234
      Leszek Swirski authored
      This is a reland of e24fa913
      It fixes the heap verification errors by going back to using MakeThin
      instead of manually creating a filler (that then makes the verifier
      think that this was array left-trimming).
      
      Original change's description:
      > [offthread] Template deserializer on Isolate
      >
      > Make the deserializer class templated on Isolate/LocalIsolate. This
      > allows the ObjectSerializer to be split into a main-thread and offthread
      > variant, with the latter taking a LocalIsolate.
      >
      > Eventually, we probably want to anyway split off the code-cache de/serializer
      > to a separate implementation (for various reasons), and this the only one that
      > wants off-thread finalization, and at this point the deserializer can revert
      > back to being un-templated, used only for bootstrapping. However, this is the
      > simplest way, for now, to enable off-thread deserialization.
      >
      > Bug: chromium:1075999
      > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75834}
      
      Bug: chromium:1075999
      Change-Id: I1d81fad2550a2a9f04dd0f9d8e66422d28faf378
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043960Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75918}
      6f898234
  13. 21 Jul, 2021 2 commits
    • Nico Hartmann's avatar
      Revert "[offthread] Template deserializer on Isolate" · c73d759b
      Nico Hartmann authored
      This reverts commit e24fa913.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview
      
      Original change's description:
      > [offthread] Template deserializer on Isolate
      >
      > Make the deserializer class templated on Isolate/LocalIsolate. This
      > allows the ObjectSerializer to be split into a main-thread and offthread
      > variant, with the latter taking a LocalIsolate.
      >
      > Eventually, we probably want to anyway split off the code-cache de/serializer
      > to a separate implementation (for various reasons), and this the only one that
      > wants off-thread finalization, and at this point the deserializer can revert
      > back to being un-templated, used only for bootstrapping. However, this is the
      > simplest way, for now, to enable off-thread deserialization.
      >
      > Bug: chromium:1075999
      > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75834}
      
      Bug: chromium:1075999
      Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75836}
      c73d759b
    • Leszek Swirski's avatar
      [offthread] Template deserializer on Isolate · e24fa913
      Leszek Swirski authored
      Make the deserializer class templated on Isolate/LocalIsolate. This
      allows the ObjectSerializer to be split into a main-thread and offthread
      variant, with the latter taking a LocalIsolate.
      
      Eventually, we probably want to anyway split off the code-cache de/serializer
      to a separate implementation (for various reasons), and this the only one that
      wants off-thread finalization, and at this point the deserializer can revert
      back to being un-templated, used only for bootstrapping. However, this is the
      simplest way, for now, to enable off-thread deserialization.
      
      Bug: chromium:1075999
      Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75834}
      e24fa913
  14. 30 Apr, 2021 1 commit
  15. 12 Apr, 2021 1 commit
  16. 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
  17. 17 Mar, 2021 1 commit
    • Nico Hartmann's avatar
      Revert "[TurboFan] Move FunctionTemplateInfo to never serialized" · c85b7a44
      Nico Hartmann authored
      This reverts commit 220e68c0.
      
      Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1188563
      
      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}
      
      TBR=neis@chromium.org
      
      No-Try: true
      No-Presubmit: true
      No-Tree-Checks: true
      Bug: v8:7790
      Change-Id: I66fd8d915e2434e3f78103b9e11dce01eb356675
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2764753Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73454}
      c85b7a44
  18. 12 Mar, 2021 1 commit
  19. 25 Feb, 2021 1 commit
  20. 10 Feb, 2021 1 commit
    • Dominik Inführ's avatar
      [codegen, heap] Improve TimeToSafepoint for concurrent compilation · d5416b99
      Dominik Inführ authored
      TimeToSafepoint is the time needed for all background threads to enter
      a safepoint after the GC was started on the main thread. This CL
      improves that metric during concurrent compilation to bytecode by doing:
      
      1) Park the LocalIsolate during
         InterpreterCompilationJob::ExecuteJobImpl. There are no concurrent
         heap accesses happening while generating bytecode for now. So instead
         of manually placing Safepoint() invocations in the code, simply park
         the local isolate.
      2) Destroy the LocalIsolate before the ReleaseParser operation. I've
         seen this take around 2ms, which regressed TimeToSafepoint a lot.
      3) Add explicit safepoints to concurrent allocations. This covers the
         rest of the code and from what I've seen so far this is good enough
         to keep TimeToSafepoint around a few microseconds.
      
      I've still seen TimeToSafepoint events with 20-80 microseconds but those
      were quite rare and always seemed to be related to Turbofan.
      
      AsLocalIsolate() is necessary in generic code to convert both Isolate
      and LocalIsolate to LocalIsolate.
      
      Bug: v8:10315
      Change-Id: Idaf9f04ffdf850d0ab0081ec372cc384a9fe7ef9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663159Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72618}
      d5416b99
  21. 25 Jan, 2021 1 commit
  22. 18 Jan, 2021 1 commit
  23. 17 Dec, 2020 1 commit
  24. 16 Dec, 2020 1 commit
    • Daniel Clark's avatar
      [modules][api] Implement HostGetSupportedImportAssertions · 8ae4dc40
      Daniel Clark authored
      Implement the HostGetSupportedImportAssertions, whose purpose
      is to filter the list of import assertions exposed to the embedder to
      only those assertion with keys that the embedder recognizes. See
      https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions.
      
      This change doesn't actually implement it as a callback, but instead
      passes the supported assertions during creation of the Isolate via
      CreateParams. This expresses clearly the requirement that the supported
      assertions must never change for the lifetime of the Isolate.
      
      Note that we still need to maintain all assertions in a map
      while parsing the import assertions clause, because duplicate keys for
      an unsupported assertion still needs to be detected as a parse error. So,
      the filtering is done later during
      SourceTextModuleDescriptor::AstModuleRequest::Serialize.
      
      The actual filtering algorithm simply iterates the assertions and the
      supported assertion keys in a nested loop. There's currently only one
      assertion in use ("type"), so there should be no reason to get too
      clever here unless at least several more assertions are generally
      supported.
      
      Bug: v8:10958
      Change-Id: I9a2d965e9d452718d0ddfe9dca55b7b4ed963019
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2572173Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71776}
      8ae4dc40
  25. 01 Dec, 2020 1 commit
  26. 23 Nov, 2020 1 commit
  27. 20 Oct, 2020 1 commit
  28. 17 Oct, 2020 1 commit
  29. 07 Oct, 2020 1 commit
  30. 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