1. 04 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      [osr] Fall back to synchronous OSR on cache mismatches · 3f5a3df6
      Jakob Gruber authored
      If we've already cached OSR'd code for the current function but with a
      different osr offset, fall back to synchronous compilation. This avoids
      degenerate cases where we repeatedly spawn OSR jobs but then fail to
      install them.
      
      Drive-by: More consistent --trace-osr output.
      Drive-by: Rename kCompileForOnStackReplacement to kCompileOptimizeOSR
      for name consistency.
      Drive-by: Add JSFunction::DebugNameCStr() for more convenient PrintF's.
      
      Bug: v8:12161
      Change-Id: I2b4a65bc9e082d85d7048a3e92ef86b07d396687
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560431Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79761}
      3f5a3df6
  2. 31 Mar, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Add lazy deopts · 0df9606d
      Leszek Swirski authored
      Nodes can now hold a LazyDeoptSafepoint which stores the frame state in
      case they trigger a lazy deopt. OpProperties have a new CanLazyDeopt
      bit, and codegen emits a safepoint table entry + lazy deopt for all
      nodes with this bit. Also, we now check the deoptimized code bit on
      entry into the maglev compiled function.
      
      An example use of these lazy deopts is added as a PropertyCell fast path
      for LdaGlobal, which adds a code dependency on the property cell.
      
      Bug: v8:7700
      Change-Id: I663db38dfa7325d38fc6d5f079d263a958074e36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557251Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79688}
      0df9606d
  3. 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
  4. 25 Mar, 2022 1 commit
  5. 21 Mar, 2022 1 commit
  6. 17 Mar, 2022 1 commit
  7. 10 Mar, 2022 1 commit
  8. 08 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently · 0d1ffe30
      Joyee Cheung authored
      For background and reasoning, see
      https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
      This is the first step towards pulling the DefineNamedOwn operation out
      of StoreIC.
      
      Summary of the renamed identifiers:
      
      Bytecodes:
      
      - StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
        normal named property sets like obj.x = 1.
      - StaNamedOwnProperty -> DefineNamedOwnProperty: calls
        DefineNamedOwnIC (previously StoreOwnIC), and emitted for
        initialization of named properties in object literals and named
        public class fields.
      - StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
        for keyed property sets like obj[x] = 1.
      - StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
        DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
        initialization of private class fields and computed public class
        fields.
      - StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
        DefineKeyedOwnPropertyInLiteral runtime function (previously
        DefineDataPropertyInLiteral) and emitted for initialization of keyed
        properties in object literals and static class initializers. (note
        that previously the StoreDataPropertyInLiteral runtime function name
        was taken by object spreads and array literal creation instead)
      - LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
        GetNamedProperty, LdaNamedPropertyFromSuper ->
        GetNamedPropertyFromSuper: we drop the Sta prefix for the property
        store operations since the accumulator use is implicit and to make
        the wording more natural, for symmetry the Lda prefix for the
        property load operations is also dropped.
      
      opcodes:
      
      - (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
        named properties, compiled from SetNamedProperty (previously
        StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
      - (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
        semantics for initializing named own properties in object literal and
        public class fields, compiled from DefineNamedOwnProperty (previously
        StaNamedOwnProperty) and lowers to DefineNamedOwnIC
        (previously StoreOwnIC)
      - (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
        for keyed properties, only compiled from SetKeyedProperty(previously
        StaKeyedProperty) and lowers to KeyedStoreIC
      - (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
        semantics for initialization of private class fields and computed
        public class fields, compiled from DefineKeyedOwnProperty (previously
        StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
        KeyedDefineOwnIC).
      - (JS)StoreDataPropertyInLiteral ->
        (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
        initialization of keyed properties in object literals and static
        class initializers, compiled from DefineKeyedOwnPropertyInLiteral
        (previously StaDataPropertyInLiteral) and calls the
        DefineKeyedOwnPropertyInLiteral runtime function (previously
        DefineDataPropertyInLiteral).
      
      Runtime:
      - DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
        following the bytecode/opcodes change, this is used by
        DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
        for object and class literal initialization.
      - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
        it's just a simplified version of DefineDataPropertyInLiteral that
        does not update feedback or perform function name configuration.
        This is used by object spread and array literal creation. Since we
        are renaming DefineDataPropertyInLiteral to
        DefineKeyedOwnPropertyInLiteral, rename this simplified version with
        a `_Simple` suffix. We can consider merging it into
        DefineKeyedOwnPropertyInLiteral in the future. See
        https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
      - Other changes following the bytecode/IR changes
      
      IC:
      
      - StoreOwn -> DefineNamedOwn: used for initialization of named
        properties in object literals and named public class fields.
        - StoreOwnIC -> DefineNamedOwnIC
        - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
        - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
        - IsStoreOwn() -> IsDefineNamedOwn()
      - DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
        IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
        keyed defines so we don't need an extra generic predicate.
        - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
        - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
        - IsDefineOwn() -> IsDefineKeyedOwn()
        - IsDefineOwnIC() -> IsDefineKeyedOwnIC()
        - Removing IsKeyedDefineOwnIC() as its now a duplicate of
          IsDefineKeyedOwnIC()
      - KeyedDefineOwnIC -> DefineKeyedOwnIC,
        KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
        make the ordering of terms more consistent
      - IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
        DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
        removed since it's just a duplicate of this.
      - IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
        "keyed" part came from, but it's only used when DefineNamedOwnIC
        (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly
      
      Interpreter & compiler:
      - BytecodeArrayBuilder: following bytecode changes
          - StoreNamedProperty -> SetNamedProperty
        - StoreNamedOwnProperty -> DefineNamedOwnProperty
        - StoreKeyedProperty -> SetKeyedProperty
        - DefineKeyedProperty -> DefineKeyedOwnProperty
        - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
      - FeedbackSlotKind:
        - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
          consistent
        - kStoreOwnNamed -> kDefineNamedOwn: following the IC change
        - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
          used in StoreIC for set semantics
        - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
          in KeyedStoreIC for set semantics
        - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
          following the IC change
      - BytecodeGraphBuilder
        - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
          is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
          difference between SetNamedProperty and DefineNamedOwnProperty
          operations.
      
      Not changed:
      
      - StoreIC and KeyedStoreIC currently contain mixed logic for both Set
        and Define operations, and the paths are controlled by feedback. The
        plan is to refactor the hierarchy like this:
        ```
        - StoreIC
          - DefineNamedOwnIC
          - SetNamedIC (there could also be a NamedStoreIC if that's helpful)
          - KeyedStoreIC
            - SetKeyedIC
            - DefineKeyedOwnIC
            - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
            - StoreInArrayLiteralIC
          - ...
        ```
        StoreIC and KeyedStoreIC would then contain helpers shared by their
        subclasses, therefore it still makes sense to keep the word "Store"
        in their names since they would be generic base classes for both set
        and define operations.
      - The Lda and Sta prefixes of bytecodes not involving object properties
        (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
        property operations, and distinction between Set and Define might be
        less relevant or nonexistent for bytecodes not involving object
        properties. We could consider rename some of them in future patches
        if that's helpful though.
      
      Bug: v8:12548
      Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79409}
      0d1ffe30
  9. 03 Mar, 2022 1 commit
  10. 02 Mar, 2022 1 commit
    • Jakob Gruber's avatar
      [maglev] Basic tiering to Maglev · 123c38a5
      Jakob Gruber authored
      When --maglev is set, tier up to Maglev from unoptimized tiers based on
      --interrupt-budget-for-maglev, initially set to 40KB (which should very
      roughly by 1/10th of the time until the TF tierup decision is made).
      On the first interrupt, a non-concurrent optimization to Maglev is
      requested, which the next call to the marked function will perform.
      
      - There is no support for tiering from Maglev to TF yet.
      - Maglev's language support is minimal and tests are not expected to
        pass with --maglev.
      - Disable --maglev by default for now.
      
      Drive-by: fixes related to Maglev flag definitions.
      
      Bug: v8:7700
      Change-Id: I121bb3f4f3830fdd20e1d4a12d3e04f08a99be38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3500302Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79328}
      123c38a5
  11. 24 Feb, 2022 2 commits
  12. 23 Feb, 2022 3 commits
  13. 22 Feb, 2022 1 commit
    • Camillo Bruni's avatar
      [web-snapshots] Add runtime function for WebSnapshot creation Part I · a7a996ab
      Camillo Bruni authored
      This CL prepares WebSnapshot for skipping and re-injecting external
      references in the web snapshot. External references are encoded as
      separate object type and allows us to create partial snapshots at
      runtime and reconnect a deserialised snapshot to an existing
      object graph.
      
      Part II will also collect all objects which cannot be serialized by the
      web-snapshot serializer.
      
      Usage:
        snapshot = %WebSnapshotSerialize(root, skip_externals);
        object = %eWebSnapshotDeserializ(snapshot, replaced_externals);
      
      Drive-by-changes:
      - Reduce JSObject Map size in serializer (we ended up with 4 embedder
        fields)
      - Avoid adding non-HeapObject to the discovery_queue_
      - Split off ReadXXX handlers into separate functions
      
      Bug: v8:11525
      Change-Id: Ia6a9914259614c6c288667621b38daa0202d4d72
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3461936Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79211}
      a7a996ab
  14. 18 Feb, 2022 1 commit
    • Michael Achenbach's avatar
      Revert "[shared-struct] Prototype JS shared structs" · c1078b5e
      Michael Achenbach authored
      This reverts commit 1025bf26.
      
      Reason for revert: https://crbug.com/v8/12645
      
      Original change's description:
      > [shared-struct] Prototype JS shared structs
      >
      > Unlike the Stage 1 proposal, for simplicity the prototype does not add
      > any new syntax, instead opting for exposing a SharedStructType
      > constructor which takes an array of field names. This type constructor
      > returns constructors for shared structs.
      >
      > Shared structs can be shared across Isolates, are fixed layout, have no
      > prototype, have no .constructor, and can only store primitives and
      > other shared structs.
      >
      > The initial prototype does not have TurboFan support.
      >
      > Bug: v8:12547
      > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79156}
      
      Bug: v8:12547
      Change-Id: I44f2b8bb7487b4d39ba1282585e0b2282501230f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474676
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79170}
      c1078b5e
  15. 17 Feb, 2022 1 commit
  16. 16 Feb, 2022 1 commit
  17. 15 Feb, 2022 1 commit
  18. 14 Feb, 2022 1 commit
    • Dominik Inführ's avatar
      Reland^3 [heap] Support client-to-shared refs in Code objects · e459c84b
      Dominik Inführ authored
      This is a reland of 2694b75e
      
      The reason for the revert was fixed and landed in
      https://crrrev.com/c/3456023, together with all changes in d8.cc. This
      reland itself doesn't change the CL apart from rebasing.
      
      Original change's description:
      > Reland "Reland "[heap] Support client-to-shared refs in Code objects""
      >
      > This is a reland of 4b8f1b1c
      >
      > After landing https://crrev.com/c/3447371, we can reland this CL as-is
      > correctness-wise.
      >
      > What's new in this CL is that we now treat references from client
      > objects into the shared heap as roots for the --track-retaining-path
      > feature.
      >
      > Original change's description:
      > > Reland "[heap] Support client-to-shared refs in Code objects"
      > >
      > > This is a reland of 12e46091
      > >
      > > Original change's description:
      > > > [heap] Support client-to-shared refs in Code objects
      > > >
      > > > Support references from code objects in the client heaps to shared heap objects. Such references are stored in a remembered set during marking, which is later used for updating pointers.
      > > >
      > > > Bug: v8:11708
      > > > Change-Id: I8aeb508ddd14514ca65fa5acf3030dd8c2040168
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401588
      > > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > > > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > > > Cr-Commit-Position: refs/heads/main@{#78819}
      > >
      > > Bug: v8:11708
      > > Change-Id: I47bcf44b452fcffe8675fba03244b736ede14247
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422630
      > > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#78838}
      >
      > Bug: v8:11708
      > Change-Id: I5b48e942fa469eabb40e797e221d06c25af16443
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3425358
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79023}
      
      Bug: v8:11708
      Change-Id: I83de1dc4dc4701cba4936a68923f6d9b97f7a6a8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455242Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79070}
      e459c84b
  19. 10 Feb, 2022 3 commits
  20. 28 Jan, 2022 2 commits
  21. 27 Jan, 2022 4 commits
  22. 26 Jan, 2022 5 commits
  23. 20 Jan, 2022 1 commit
  24. 17 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Decouple async event delegate instrumentation from PromiseHooks. · b46d5ffb
      Benedikt Meurer authored
      As described in https://crbug.com/1287476, the fact that the
      AsyncEventDelegate is currently implemented on top of the PromiseHooks
      causes performance problems and makes it difficult to reason about the
      exact (observed) semantics; this is because for this we intercept every
      JSPromise creation (via PromiseHook::kInit) and walk the synchronous
      stack at that point to see if we find one of Promise#then(),
      Promise#catch() or Promise#finally() on the stack. And if we do so, we
      report that to the AsyncEventDelegate (which is implemented in the
      inspector and will then do the async stack/stepping logic on top).
      
      This CL introduces dedicated instrumentation for Promise#then(), which
      is also called from Promise#catch() and Promise#finally(), and uses that
      instrumentation for the purpose of the AsyncEventDelegate. It also
      adjusts the stack walk to not always walk the full stack (which might
      lead to wrong results when calls to Promise#then(), which itself can
      call back into user JavaScript, are found deeper in the stack), but
      instead only check the top-most builtin frames and whatever user
      JavaScript frame is underneath it.
      
      On the standalone.js (from https://crbug.com/1287476#c1), when run with
      the DevTools default of maxDepth=200, we go from around 4.00ms to around
      0.36ms. For everything that does not call Promise#then() - either
      explicitly or implicitly - or `await`s, there's now no observable
      performance impact of turning on the AsyncEventDelegate.
      
      Bug: chromium:1280519
      Fixed: chromium:1287476
      Change-Id: I4911bed146381fc46cfeefb763d6dfc32e8f6071
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386379
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78640}
      b46d5ffb
  25. 14 Jan, 2022 3 commits