1. 13 May, 2022 1 commit
  2. 10 May, 2022 1 commit
  3. 03 May, 2022 1 commit
  4. 25 Apr, 2022 1 commit
    • jameslahm's avatar
      Reland "[interpreter] Optimize strict equal boolean" · fce1047f
      jameslahm authored
      This is a reland of commit 62632c08.
      Reason for previous revert: Performance regressions crbug.com/1315724.
      The reland only optimizes strict equal boolean literal like "a===true"
      or "a===false", and we generate TestReferenceEqual rather than
      TestStrictEqual for the comparasion. And also add typed optimization
      for ReferenceEqual when all inputs are boolean with boolean constant.
      
      Original change's description:
      > [interpreter] Optimize strict equal boolean
      >
      > For strict equal boolean literal like "a===true"
      > or "a===false", we could generate TestReferenceEqual
      > rather than TestStrictEqual. And in `execution_result()->IsTest()`
      > case, we could directly emit JumpIfTrue/JumpIfFalse.
      >
      > E.g.
      > ```
      > a === true
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > ```
      > To:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestReferenceEqual
      > ```
      >
      > E.g.
      > ```
      > if (a === true)
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > JumpIfFalse
      > ```
      > To
      > ```
      > LdaGlobal
      > JumpIfTrue
      > Jump
      > ```
      >
      >
      > Bug: v8:6403
      > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: 王澳 <wangao.james@bytedance.com>
      > Cr-Commit-Position: refs/heads/main@{#79935}
      
      Bug: v8:6403
      Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80141}
      fce1047f
  5. 22 Apr, 2022 1 commit
  6. 20 Apr, 2022 1 commit
  7. 19 Apr, 2022 1 commit
    • Jakob Linke's avatar
      Revert "[interpreter] Optimize strict equal boolean" · 3b772a23
      Jakob Linke authored
      This reverts commit 62632c08.
      
      Reason for revert: Performance regressions crbug.com/1315724
      
      Original change's description:
      > [interpreter] Optimize strict equal boolean
      >
      > For strict equal boolean literal like "a===true"
      > or "a===false", we could generate TestReferenceEqual
      > rather than TestStrictEqual. And in `execution_result()->IsTest()`
      > case, we could directly emit JumpIfTrue/JumpIfFalse.
      >
      > E.g.
      > ```
      > a === true
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > ```
      > To:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestReferenceEqual
      > ```
      >
      > E.g.
      > ```
      > if (a === true)
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > JumpIfFalse
      > ```
      > To
      > ```
      > LdaGlobal
      > JumpIfTrue
      > Jump
      > ```
      >
      >
      > Bug: v8:6403
      > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: 王澳 <wangao.james@bytedance.com>
      > Cr-Commit-Position: refs/heads/main@{#79935}
      
      Bug: v8:6403, chromium:1315724
      Change-Id: I65c520590093724e838f738c795d229687efb9de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#80010}
      3b772a23
  8. 12 Apr, 2022 1 commit
    • jameslahm's avatar
      [interpreter] Optimize strict equal boolean · 62632c08
      jameslahm authored
      For strict equal boolean literal like "a===true"
      or "a===false", we could generate TestReferenceEqual
      rather than TestStrictEqual. And in `execution_result()->IsTest()`
      case, we could directly emit JumpIfTrue/JumpIfFalse.
      
      E.g.
      ```
      a === true
      ```
      Generated Bytecode From:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestEqualStrict
      ```
      To:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestReferenceEqual
      ```
      
      E.g.
      ```
      if (a === true)
      ```
      Generated Bytecode From:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestEqualStrict
      JumpIfFalse
      ```
      To
      ```
      LdaGlobal
      JumpIfTrue
      Jump
      ```
      
      
      Bug: v8:6403
      Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: 王澳 <wangao.james@bytedance.com>
      Cr-Commit-Position: refs/heads/main@{#79935}
      62632c08
  9. 23 Mar, 2022 1 commit
  10. 10 Mar, 2022 1 commit
  11. 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
  12. 03 Mar, 2022 1 commit
  13. 15 Feb, 2022 1 commit
  14. 10 Feb, 2022 1 commit
  15. 02 Feb, 2022 1 commit
  16. 24 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      Reland "[class] implement reparsing of class instance member initializers" · 0e07eb53
      Joyee Cheung authored
      This is a reland of 91f08378
      
      When the class scope does not need a context, the deserialized
      outer scope of the initializer scope would not be the class scope,
      and we should not and do not need to use it to fix up the allocation
      information of the context-allocated variables. The original patch
      did not consider this case and resulted in a regression when we
      tried to reparse the initializer function to look for destructuring
      assignment errors. This fixes the regression by not deserializing
      the class scope that's going to be reparsed, and using the positions
      of the scopes to tell whether the scope info matches the reparsed
      scope and can be used to fix up the allocation info.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: chromium:1278086, chromium:1278085, v8:10704
      Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78745}
      0e07eb53
  17. 13 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored
      This unifies and simplifies the way we instrument async functions for
      the purpose of async stack traces and async stepping. It does so while
      retaining the observable behavior on the inspector level (for now).
      
      Previously we'd mark the implicit promise of the async function object
      with the async task ID, and whenever we awaited, we'd copy the async
      task ID to the throwaway promise that is created by the `await`. This
      however made things unnecessarily interesting in the following regards:
      
      1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
      `AsyncFunctionFinished` events, coming from the throwaway promises,
      while the implicit promise is "done". This is especially confusing
      with rejection propagation and requires very complex stepping logic
      for async functions (after this CL it'll be possible to unify and
      simplify the stepping logic).
      2. We have to thread through the "can suspend" information from the
      Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
      to the async function instrumentation to decide whether to cancel the
      pending task when the async function finishes.
      
      This CL changes the instrumentation to only happen (non recurringly) for
      the throwaway promises allocated upon `await`. This solves both problems
      mentioned above, and works because upon the first `await` the stack
      captured for the throwaway promise will include the synchronous part as
      expected, while upon later `await`s the synchronous part will be empty
      and the asynchronous part will be the stack captured for the previous
      throwaway promise (and the V8Debugger automatically short circuits
      stacks with empty synchronous part).
      
      Bug: chromium:1280519, chromium:1277451, chromium:1246867
      Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  18. 09 Dec, 2021 1 commit
    • Joyee Cheung's avatar
      Revert "[class] implement reparsing of class instance member initializers" · f668e9f7
      Joyee Cheung authored
      This reverts commit 91f08378.
      
      Reason for revert: It's a fairly big change, and the clusterfuzz
      found some bugs. Will reland with the fix after M98 branch point.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: v8:10704
      Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
      Auto-Submit: Joyee Cheung <joyee@igalia.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78315}
      f668e9f7
  19. 08 Dec, 2021 2 commits
    • Joyee Cheung's avatar
      [class] implement reparsing of class instance member initializers · 91f08378
      Joyee Cheung authored
      Previously, since the source code for the synthetic class instance
      member initializer function was recorded as the span from the first
      initializer to the last initializer, there was no way to reparse the
      class and recompile the initializer function. It was working for
      most use cases because the code for the initializer function was
      generated eagarly and it was usually alive as long as the class was
      alive, so the initializer wouldn't normally be lazily parsed. This
      didn't work, however, when the class was snapshotted with
      v8::SnapshotCreator::FunctionCodeHandling::kClear,
      becuase then we needed to recompile the initializer when the class
      was instantiated. This patch implements the reparsing so that
      these classes can work with FunctionCodeHandling::kClear.
      
      This patch refactors ParserBase::ParseClassLiteral() so that we can
      reuse it for both parsing the class body normally and reparsing it
      to collect initializers. When reparsing the synthetic initializer
      function, we rewind the scanner to the beginning of the class, and
      parse the class body to collect the initializers. During the
      reparsing, field initializers are parsed with the full parser while
      methods of the class are pre-parsed.
      
      A few notable changes:
      
      - Extended the source range of the initializer function to cover the
        entire class so that we can rewind the scanner to parse the class
        body to collect initializers (previously, it starts from the first
        field initializer and ends at the last initializer). This resulted
        some expectation changes in the debugger tests, though the
        initializers remain debuggable.
      - A temporary ClassScope is created during reparsing. After the class
        is reparsed, we use the information from the ScopeInfo to update
        the allocated indices of the variables in the ClassScope.
      
      Bug: v8:10704
      Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78299}
      91f08378
    • 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
  20. 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
  21. 01 Dec, 2021 2 commits
    • 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
    • Leszek Swirski's avatar
      [interpreter] Don't emit dead try blocks · a858cfd3
      Leszek Swirski authored
      Try blocks (whether catch or finally) will unconditionally create
      handler tables and start a new basic block for the exception handler.
      This can accidentally resurrect a dead block when the entire try block
      is dead (and hence can never enter the exception handler in the first
      place).
      
      Add a deadness check to BuildTryCatch/Finally to fix this.
      
      Bug: chromium:1273677
      Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78179}
      a858cfd3
  22. 19 Nov, 2021 1 commit
  23. 17 Nov, 2021 1 commit
  24. 15 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Post compile tasks from ignition instead of the parser · 6b2fa4c1
      Leszek Swirski authored
      Posting compile tasks from the parser has several issues:
      
        1. We don't know how many functions there will be total, so we can't
           yet allocate shared_function_infos array on the Script
        2. Without this array, inner function compiles can't look up their own
           inner functions during bytecode finalization, so we can't run that
           finalization before script parse completes
        3. Scope analysis can't have run yet, so we can only post top-level
           function tasks and if we allocate SharedFunctionInfos early they
           are forced into a bit of a limbo state without an outer ScopeInfo.
      
      Instead, we can post compile tasks during bytecode generation. Then, the
      script parse is guaranteed to have completed, so we'll have a
      shared_function_infos array and we will have allocated ScopeInfos
      already. This also opens the door for posting tasks for compiling more
      inner functions than just top-level, as well as generating better code
      for functions/methods that reference same-script top-level
      let/const/class.
      
      Bug: chromium:1267680
      Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77894}
      6b2fa4c1
  25. 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
  26. 02 Nov, 2021 1 commit
  27. 18 Oct, 2021 1 commit
  28. 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
  29. 30 Sep, 2021 1 commit
  30. 27 Sep, 2021 1 commit
  31. 27 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Clobber accumulator in StaGlobal · 732f394c
      Leszek Swirski authored
      StaGlobal didn't write the accumulator, but the baseline implementation
      assumed that it could preserve the accumulator by taking the return
      value of the StoreGlobalIC. This almost always worked, except for
      setters on the global object.
      
      Fix this by marking StaGlobal as clobbering the accumulator, same as
      StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
      inlined setters from needing to create accumulator-preserving frames;
      StaGlobal would have needed the same thing if we'd ever inlined setters
      for it).
      
      Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
      baseline compiler, which checks if the accumulator value is preserved
      across non-accumulator-writing bytecodes. This found a (benign) bug with
      ForInPrepare, so fix that too.
      
      Fixed: chromium:1242306
      Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76525}
      732f394c
  32. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  33. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  34. 13 Aug, 2021 1 commit
    • Nicolò Ribaudo's avatar
      [class] Improve errors for reinitialized private elements · b3b9466a
      Nicolò Ribaudo authored
      Previously V8 was reusing the error fur duplicate declarations, using
      the private name for class fields or the class name for class methods
      as the redeclared identifier.
      
          class A { constructor(o) { return o } }
          class B extends A { #x }
          class C extends A { #x() {} }
          let D = (0, class extends A { #x() {} });
      
          new B(new B({})) // Identifier '#x' has already been declared
          new C(new C({})) // Identifier 'C' has already been declared
          new D(new D({})) // Identifier '' has already been declared
      
      This patch changes it to use error messages that better explain what's
      happening:
      
          new B(new B({})) // Cannot initialize #x twice on the same object
          new C(new C({})) // Cannot initialize private methods of
                           // class C twice on the same object
          new D(new D({})) // Cannot initialize private methods of
                           // class anonymous twice on the same object
      
      I initially tried to use the same message for both fields and methods,
      but the problem with that is that when initializing fields we only
      have access to the field name, while when initializing methods we only
      have access to the class name (using the "private brand" symbol).
      However, almost all the error messages are different for private fields
      and for methods so this shouldn't be a problem.
      
      Bug: v8:12042
      Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJoyee Cheung <joyee@igalia.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76279}
      b3b9466a
  35. 09 Aug, 2021 2 commits
  36. 01 Jul, 2021 1 commit