1. 06 Jul, 2022 1 commit
  2. 01 Jul, 2022 1 commit
  3. 20 Jun, 2022 1 commit
  4. 25 May, 2022 1 commit
  5. 24 May, 2022 1 commit
  6. 23 May, 2022 1 commit
  7. 19 May, 2022 1 commit
  8. 13 May, 2022 1 commit
  9. 12 May, 2022 1 commit
  10. 06 Apr, 2022 1 commit
  11. 31 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] name Set/Define/Store property operations more consistently pt.2 · cf5ce194
      Joyee Cheung authored
      As a follow-up of
      https://chromium-review.googlesource.com/c/v8/v8/+/3481475,
      this renames a few more operations related to property stores to keep
      them consistent and adds comments to explain about what they do.
      
      Summary of the renamed identifiers:
      
      - SetPropertyInLiteral -> CreateDataProperty: this implements
        [[CreateDataProperty]] in the spec which does [[DefineOwnProperty]]
        instead of [[Set]], so rename for clarity.
      - IsStoreIC(), IsStoreICKind() -> IsSetNamedIC(), IsSetNamedICKind():
        these only check whether the feedback kind is kSetNamedSloppy or
        kSetNamedStrict, so the scope can be narrowed.
      - StoreMode::kOrdinary -> StoreMode::kSet: this implements [[Set]]
        in the spec and is used by both KeyedStoreIC and
        StoreIC to set the properties when there is no feedback.
      - StoreMode::kInLiteral -> StoreMode::kDefineKeyedOwnInLiteral:
        this implements [[CreateDataProperty]] while expecting the receiver
        to be a JSObject created by us (the `InLiteral` part). Prepend
        `DefineKeyedOwn` to it so that it's more aligned with other
        StoreModes - it should be possible to just merge this into the
        more generic StoreMode::kDefineKeyedOwn later.
      - KeyedStoreGenericAssembler::SetProperty ->
        KeyedStoreGenericAssembler::StoreProperty: these helpers are used by
        both define and set operations, distinguished with the StoreMode,
        so rename it to the more generic StoreProperty.
      
      Bug: v8:12548
      Change-Id: Iccef673c1dc707bbdbf010f02f7db1e9ec32b3e4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557690Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79694}
      cf5ce194
  12. 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
  13. 24 Mar, 2022 1 commit
    • Joyee Cheung's avatar
      [ic] fix handling of existing properties in Define{Keyed|Named}OwnIC · 4ee68d81
      Joyee Cheung authored
      - When the property being defined with DefineKeyedOwnIC or
        DefineNamedOwnIC already exists, we should use the slow path to
        check if the operation is allowed in case the property is
        non-configurable or Object.preventExtensions() has been called on
        the property.
      - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a
        name, we should use Runtime::DefineObjectOwnProperty() for
        DefineKeyedOwnIC too.
      - When dealing with public fields, Runtime::DefineObjectOwnProperty()
        should use JSReceiver::CreateDataProperty() instead of
        Object::SetProperty() for the specified semantics. This patch also
        adds JSReceiver::AddPrivateField() for it and StoreIC::Store to
        define private fields without triggering traps or checking
        extensibility.
      - To emit a more specific error message when redefining properties
        on non-extensible objects, Object::AddDataProperty() now also takes
        a EnforceDefineSemantics enum to distinguish between set and define.
      - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for
        extensibility even if the configurability check passes.
      
      Bug: chromium:1259950, v8:9888
      Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#79603}
      4ee68d81
  14. 09 Mar, 2022 1 commit
    • Camillo Bruni's avatar
      [runtime] Clean up runtime function Arguments accesses · cead6573
      Camillo Bruni authored
      Replace all CONVERT_XXX_ARG_XXX() macros from runtime-util.h with direct
      calls to Arguments or the fully expanded equivalent.
      
      - This replaces many of the hard CHECKs with DCHECK (as is common
        practice in most V8 code)
      - Instead of relying on verbose comments we now have readable code
      - Rename Arguments.::xxx_at with Arguments::xxx_value_at since these
        methods don't return the Object but rather their double/int value
      
      - Add Oddball::ToBool helper
      - Add and use v8::internal::PropertyAttributesFromInt helper
      - Add stronger DCHECK for PropertyAttributes returned in
        GetPropertyAttributesWithInterceptorInternal
      
      
      
      Bug: v8:11263
      Change-Id: I8d531857e05d19f3198753b05af28d993a391854
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497768Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79418}
      cead6573
  15. 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
  16. 23 Feb, 2022 1 commit
  17. 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
  18. 17 Feb, 2022 1 commit
  19. 15 Feb, 2022 1 commit
  20. 31 Jan, 2022 1 commit
  21. 27 Jan, 2022 1 commit
  22. 18 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      [class] handle existing readonly properties in StoreOwnIC · 80bbbb14
      Joyee Cheung authored
      Previously, StoreOwnIC incorrectly reuses the [[Set]] semantics
      when initializing public literal class fields and object literals in
      certain cases (e.g. when there's no feedback).
      This was less of an issue for object literals, but with public class
      fields it's possible to define property attributes while the
      instance is still being initialized, or to encounter existing static
      "name" or "length" properties that should be readonly. This patch
      fixes it by
      
      1) Emitting code that calls into the slow stub when
         handling StoreOwnIC with existing read-only properties.
      2) Adding extra steps in StoreIC::Store to handle such stores
         properly with [[DefineOwnProperty]] semantics.
      
      Bug: v8:12421, v8:9888
      Change-Id: I6547320a1caba58c66ee1043cd3183a2de7cefef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300092Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78659}
      80bbbb14
  23. 11 Jan, 2022 1 commit
  24. 19 Nov, 2021 1 commit
  25. 17 Nov, 2021 1 commit
  26. 15 Nov, 2021 1 commit
  27. 09 Nov, 2021 1 commit
    • Joyee Cheung's avatar
      [class] fix evaluation order and errors in private accessor assignments · f77b05d4
      Joyee Cheung authored
      In assignments the lhs should be evaluated first and shouldn't be
      re-evaluated when the value of the rhs is available. Fix it by
      saving the receiver and the key registers into AssignmentLhsData
      before building the assignment and use them later, instead of visiting
      the AST again to retrieve the receiver.
      
      In addition, now that we save the receiver register, use it to
      perform the brand check even when we know for sure that it's
      going to fail later because it's a write to a private
      method or accessing the accessor in the wrong way (v8:11364),
      so that the brand check error always appears first if it is present,
      as specified in
      https://tc39.es/proposal-private-methods/#sec-privatefieldget
      
      Drive-by: unify the brand check error messages, and replace "Object"
      with "Receiver" in the messages for clarity. The instance private
      brand check now throws "Receiver must be an instance of class <name>"
      and the static private brand check now throws "Receiver must be
      class <name>". Also always set the expression position to the
      property load position, because the brand check failure comes from
      the load operation.
      
      Bug: v8:12352, v8:11364
      Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77797}
      f77b05d4
  28. 04 Nov, 2021 1 commit
    • Shu-yu Guo's avatar
      [ic] Add StoreOwnIC_Slow · 1cc12b27
      Shu-yu Guo authored
      This runtime function behaves like StoreDataPropertyInLiteral, except it
      can throw, since it's also used for defining public class fields. Unlike
      the literal use case, class field can end up throwing due to field
      initializers doing things like freezing the instance.
      
      Bug: chromium:1264828
      Change-Id: I3ea4d15ad9b906c26763f022c8e22b757fa80b6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3252558
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Auto-Submit: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77704}
      1cc12b27
  29. 02 Nov, 2021 1 commit
  30. 01 Nov, 2021 1 commit
  31. 28 Oct, 2021 1 commit
  32. 27 Oct, 2021 1 commit
  33. 18 Oct, 2021 2 commits
  34. 13 Oct, 2021 1 commit
    • Joyee Cheung's avatar
      [class] Add IC support for defining class fields to replace runtime call · 713ebae3
      Joyee Cheung authored
      Introduces several new runtime mechanics for defining private fields,
      including:
        - Bytecode StaKeyedPropertyAsDefine
        - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
        - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
        - TurboFan IR opcode JSDefineProperty
      
      These new operations can reduce a runtime call per class field into a
      more traditional Store equivalent. In the microbenchmarks, this
      results in a substantial win over the status quo (~8x benchmark score
      for single fields with the changes, ~20x with multiple fields).
      
      The TurboFan JSDefineProperty op is lowered in
      JSNativeContextSpecialization, however this required some hacks.
      Because private fields are defined as DONT_ENUM when added to the
      object, we can't find a suitable transition using the typical data
      property (NONE) flags. I've added a mechanism to specify the required
      PropertyAttributes for the transition we want to look up.
      
      Details:
      
      New bytecodes:
        - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
          but with a different IC builtin (KeyedDefineOwnIC). This is a
          bytecode rather than a flag for the existing StaKeyedProperty in
          order to avoid impacting typical keyed stores in any way due to
          additional branching and testing.
      
      New builtins:
        - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
          StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
          no longer look up the property name in the prototype.
          In adddition, this CL changes an assumption that
          StoreNamedOwnProperty can't result in a map transition, as we
          can't rely on the property already being present in the Map due
          to an object literal boilerplate.
      
          In the context of class features, this replaces the runtime
          function %CreateDataProperty().
      
        - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
          new StaKeyedPropertyAsDefine bytecode. This is similar to an
          ordinary KeyedStoreIC, but will not check the prototype for
          setters, and for private fields, will take the slow path if the
          field already exists.
      
          In the context of class features, this replaces the runtime
          function %AddPrivateField().
      
      TurboFan IR:
        - JSDefineProperty is introduced to represent a situation where we
          need to use "Define" semantics, in particular, it codifies that we
          do not consult the prototype chain, and the semantics relating to
          private fields are implied as well.
      
      R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
      
      Bug: v8:9888
      Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#77377}
      713ebae3
  35. 28 Sep, 2021 1 commit
  36. 27 Sep, 2021 1 commit
  37. 09 Sep, 2021 1 commit
  38. 11 Aug, 2021 1 commit
  39. 02 Aug, 2021 1 commit
    • Kevin Babbitt's avatar
      Update inline cache after migrating deprecated map · 0c10dda4
      Kevin Babbitt authored
      Previously, when the Load IC saw a deprecated map, it would migrate to
      the new map but not update the feedback vector. This would lead to a
      deopt the next time the same object was seen.
      
      With this CL, the feedback vector will be updated to the target of the
      deprecated map. In order to do this, we need to mark the IC for
      recomputation. Without that call, the map and handler would look the
      same to IC::UpdatePolymorphicIC amd would decline to update, causing
      the IC to go megamorphic instead.
      
      Bug: v8:10816
      Change-Id: I0dcf97fb278bc0b167df6ce24d5db179f599f535
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032983Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#76042}
      0c10dda4