1. 19 Aug, 2022 1 commit
    • Shu-yu Guo's avatar
      [shared-struct] Make publishing of shared objects safe · 4266684c
      Shu-yu Guo authored
      Currently there is nothing ensuring the internal VM state of shared
      objects are in a coherent state and visible to other threads when the
      shared object is published.
      
      This CL adds a store-store memory barrier when returning from Factory methods that allocate shared JSObjects that are exposed to user JS code. For primitives, there is an additional store-store memory barrier in the shared value barrier.
      
      Bug: v8:12547
      Change-Id: I4833c7ebf02cc352da9b006d2732669d6d043172
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng,v8_linux64_tsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819041
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82596}
      4266684c
  2. 18 Aug, 2022 1 commit
  3. 17 Aug, 2022 1 commit
  4. 12 Aug, 2022 1 commit
  5. 05 Aug, 2022 1 commit
  6. 02 Aug, 2022 2 commits
  7. 28 Jul, 2022 1 commit
    • Seth Brenith's avatar
      Reland "Background merging of deserialized scripts" · 766b2a4d
      Seth Brenith authored
      This is a reland of commit e895b7af
      
      The unit test has been updated to work correctly when
      --stress-incremental-marking is enabled.
      
      Original change's description:
      > Background merging of deserialized scripts
      >
      > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
      > with which an embedder could request that V8 merge newly deserialized
      > script data into an existing Script from the Isolate's compilation
      > cache. This change implements those new functions. This functionality is
      > still disabled by default due to the flag
      > merge_background_deserialized_script_with_compilation_cache.
      >
      > The goal of this new functionality is to reduce memory usage when
      > multiple frames load the same script with a long delay between (long
      > enough for the script to have been evicted from Blink's in-memory cache
      > and for the top-level SharedFunctionInfo to be flushed). In that case,
      > there are two Script objects for the same script: one which was found in
      > the Isolate compilation cache (the "old" script), and one which was
      > recently deserialized (the "new" script). The new script's object graph
      > is essentially standalone: it may point to internalized strings and
      > readonly objects such as the empty feedback metadata, but otherwise
      > it is unconnected to the rest of the heap. The merging logic takes any
      > useful data from the new script's object graph and attaches it into the
      > old script's object graph, so that the new Script object and any other
      > duplicated objects can be discarded. More specifically:
      >
      > 1. If the new Script has a SharedFunctionInfo for a particular function
      >    literal, and the old Script does not, then the old Script is updated
      >    to refer to the new SharedFunctionInfo.
      > 2. If the new Script has a compiled SharedFunctionInfo for a particular
      >    function literal, and the old Script has an uncompiled
      >    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
      >    point to the function_data and feedback_metadata from the new
      >    SharedFunctionInfo.
      > 3. If any used object from the new object graph points to a
      >    SharedFunctionInfo, where the old object graph contains a matching
      >    SharedFunctionInfo for the same function literal, then that pointer
      >    is updated to point to the old SharedFunctionInfo.
      >
      > The document at [0] includes diagrams showing an example merge on a very
      > small script.
      >
      > Steps 1 and 2 above are pretty simple, but step 3 requires walking a
      > possibly large set of objects, so this new API lets the embedder run
      > step 3 from a background thread. Steps 1 and 2 are performed later, on
      > the main thread.
      >
      > The next important question is: in what ways can the old script's object
      > graph be modified during the background execution of step 3, or during
      > the time after step 3 but before steps 1 and 2?
      >
      > A. SharedFunctionInfos can go from compiled to uncompiled due to
      >    flushing. This is okay; the worst outcome is that the function would
      >    need to be compiled again later. Such a risk is already present,
      >    since V8 doesn't keep IsCompiledScopes for every compiled function in
      >    a background-deserialized script.
      > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
      >    compilation. This is also okay; the merge completion logic on the
      >    main thread will just keep this lazily compiled data rather than
      >    inserting compiled data from the newly deserialized object graph.
      > C. SharedFunctionInfos can be cleared from the Script's weak array if
      >    they are no longer referenced. This is mostly okay, because any
      >    SharedFunctionInfo that is needed by the background merge is strongly
      >    referenced and therefore can't be cleared. The only problem arises if
      >    the top-level SharedFunctionInfo gets cleared, so the merge task must
      >    deliberately keep a reference to that one.
      > D. SharedFunctionInfos can be created if they are needed due to lazy
      >    compilation of a parent function. This change is somewhat troublesome
      >    because it invalidates the background thread's work and requires a
      >    re-traversal on the main thread to update any pointers that should
      >    point to this lazily compiled SharedFunctionInfo.
      >
      > At a high level, this change implements three previously unimplemented
      > functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
      >
      > - BackgroundDeserializeTask::SourceTextAvailable, run on the main
      >   thread, checks whether there is a matching Script in the Isolate
      >   compilation cache which doesn't already have a top-level
      >   SharedFunctionInfo. If so, it saves that Script in a persistent
      >   handle.
      > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
      >   whether the persistent handle from the first step exists (a fast
      >   operation which can be called from any thread).
      > - BackgroundDeserializeTask::MergeWithExistingScript, run on a
      >   background thread, performs step 3 of the merge described above and
      >   generates lists of persistent data describing how the main thread can
      >   complete the merge.
      > - BackgroundDeserializeTask::Finish is updated to perform the merge
      >   steps 1 and 2 listed above, as well as a possible re-traversal of the
      >   graph if required due to newly created SharedFunctionInfos in the old
      >   Script.
      >
      > The merge logic has nothing to do with deserialization, and indeed I
      > hope to reuse it for background compilation tasks as well, so it is all
      > contained within a new class BackgroundMergeTask (in compiler.h,cc). It
      > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
      > the object visitation that updates pointers to SharedFunctionInfos.
      >
      > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
      >
      > Bug: v8:12808
      > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#81941}
      
      Bug: v8:12808
      Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#82045}
      766b2a4d
  8. 25 Jul, 2022 2 commits
    • Deepti Gandluri's avatar
      Revert "Background merging of deserialized scripts" · 44fc1fda
      Deepti Gandluri authored
      This reverts commit e895b7af.
      
      Reason for revert: TSAN failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/8468/overview
      
      Original change's description:
      > Background merging of deserialized scripts
      >
      > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
      > with which an embedder could request that V8 merge newly deserialized
      > script data into an existing Script from the Isolate's compilation
      > cache. This change implements those new functions. This functionality is
      > still disabled by default due to the flag
      > merge_background_deserialized_script_with_compilation_cache.
      >
      > The goal of this new functionality is to reduce memory usage when
      > multiple frames load the same script with a long delay between (long
      > enough for the script to have been evicted from Blink's in-memory cache
      > and for the top-level SharedFunctionInfo to be flushed). In that case,
      > there are two Script objects for the same script: one which was found in
      > the Isolate compilation cache (the "old" script), and one which was
      > recently deserialized (the "new" script). The new script's object graph
      > is essentially standalone: it may point to internalized strings and
      > readonly objects such as the empty feedback metadata, but otherwise
      > it is unconnected to the rest of the heap. The merging logic takes any
      > useful data from the new script's object graph and attaches it into the
      > old script's object graph, so that the new Script object and any other
      > duplicated objects can be discarded. More specifically:
      >
      > 1. If the new Script has a SharedFunctionInfo for a particular function
      >    literal, and the old Script does not, then the old Script is updated
      >    to refer to the new SharedFunctionInfo.
      > 2. If the new Script has a compiled SharedFunctionInfo for a particular
      >    function literal, and the old Script has an uncompiled
      >    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
      >    point to the function_data and feedback_metadata from the new
      >    SharedFunctionInfo.
      > 3. If any used object from the new object graph points to a
      >    SharedFunctionInfo, where the old object graph contains a matching
      >    SharedFunctionInfo for the same function literal, then that pointer
      >    is updated to point to the old SharedFunctionInfo.
      >
      > The document at [0] includes diagrams showing an example merge on a very
      > small script.
      >
      > Steps 1 and 2 above are pretty simple, but step 3 requires walking a
      > possibly large set of objects, so this new API lets the embedder run
      > step 3 from a background thread. Steps 1 and 2 are performed later, on
      > the main thread.
      >
      > The next important question is: in what ways can the old script's object
      > graph be modified during the background execution of step 3, or during
      > the time after step 3 but before steps 1 and 2?
      >
      > A. SharedFunctionInfos can go from compiled to uncompiled due to
      >    flushing. This is okay; the worst outcome is that the function would
      >    need to be compiled again later. Such a risk is already present,
      >    since V8 doesn't keep IsCompiledScopes for every compiled function in
      >    a background-deserialized script.
      > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
      >    compilation. This is also okay; the merge completion logic on the
      >    main thread will just keep this lazily compiled data rather than
      >    inserting compiled data from the newly deserialized object graph.
      > C. SharedFunctionInfos can be cleared from the Script's weak array if
      >    they are no longer referenced. This is mostly okay, because any
      >    SharedFunctionInfo that is needed by the background merge is strongly
      >    referenced and therefore can't be cleared. The only problem arises if
      >    the top-level SharedFunctionInfo gets cleared, so the merge task must
      >    deliberately keep a reference to that one.
      > D. SharedFunctionInfos can be created if they are needed due to lazy
      >    compilation of a parent function. This change is somewhat troublesome
      >    because it invalidates the background thread's work and requires a
      >    re-traversal on the main thread to update any pointers that should
      >    point to this lazily compiled SharedFunctionInfo.
      >
      > At a high level, this change implements three previously unimplemented
      > functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
      >
      > - BackgroundDeserializeTask::SourceTextAvailable, run on the main
      >   thread, checks whether there is a matching Script in the Isolate
      >   compilation cache which doesn't already have a top-level
      >   SharedFunctionInfo. If so, it saves that Script in a persistent
      >   handle.
      > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
      >   whether the persistent handle from the first step exists (a fast
      >   operation which can be called from any thread).
      > - BackgroundDeserializeTask::MergeWithExistingScript, run on a
      >   background thread, performs step 3 of the merge described above and
      >   generates lists of persistent data describing how the main thread can
      >   complete the merge.
      > - BackgroundDeserializeTask::Finish is updated to perform the merge
      >   steps 1 and 2 listed above, as well as a possible re-traversal of the
      >   graph if required due to newly created SharedFunctionInfos in the old
      >   Script.
      >
      > The merge logic has nothing to do with deserialization, and indeed I
      > hope to reuse it for background compilation tasks as well, so it is all
      > contained within a new class BackgroundMergeTask (in compiler.h,cc). It
      > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
      > the object visitation that updates pointers to SharedFunctionInfos.
      >
      > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
      >
      > Bug: v8:12808
      > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#81941}
      
      Bug: v8:12808
      Change-Id: I82a080e6287828445293cb6b4b94a5e8f15eb8f3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787213
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#81943}
      44fc1fda
    • Seth Brenith's avatar
      Background merging of deserialized scripts · e895b7af
      Seth Brenith authored
      Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
      with which an embedder could request that V8 merge newly deserialized
      script data into an existing Script from the Isolate's compilation
      cache. This change implements those new functions. This functionality is
      still disabled by default due to the flag
      merge_background_deserialized_script_with_compilation_cache.
      
      The goal of this new functionality is to reduce memory usage when
      multiple frames load the same script with a long delay between (long
      enough for the script to have been evicted from Blink's in-memory cache
      and for the top-level SharedFunctionInfo to be flushed). In that case,
      there are two Script objects for the same script: one which was found in
      the Isolate compilation cache (the "old" script), and one which was
      recently deserialized (the "new" script). The new script's object graph
      is essentially standalone: it may point to internalized strings and
      readonly objects such as the empty feedback metadata, but otherwise
      it is unconnected to the rest of the heap. The merging logic takes any
      useful data from the new script's object graph and attaches it into the
      old script's object graph, so that the new Script object and any other
      duplicated objects can be discarded. More specifically:
      
      1. If the new Script has a SharedFunctionInfo for a particular function
         literal, and the old Script does not, then the old Script is updated
         to refer to the new SharedFunctionInfo.
      2. If the new Script has a compiled SharedFunctionInfo for a particular
         function literal, and the old Script has an uncompiled
         SharedFunctionInfo, then the old SharedFunctionInfo is updated to
         point to the function_data and feedback_metadata from the new
         SharedFunctionInfo.
      3. If any used object from the new object graph points to a
         SharedFunctionInfo, where the old object graph contains a matching
         SharedFunctionInfo for the same function literal, then that pointer
         is updated to point to the old SharedFunctionInfo.
      
      The document at [0] includes diagrams showing an example merge on a very
      small script.
      
      Steps 1 and 2 above are pretty simple, but step 3 requires walking a
      possibly large set of objects, so this new API lets the embedder run
      step 3 from a background thread. Steps 1 and 2 are performed later, on
      the main thread.
      
      The next important question is: in what ways can the old script's object
      graph be modified during the background execution of step 3, or during
      the time after step 3 but before steps 1 and 2?
      
      A. SharedFunctionInfos can go from compiled to uncompiled due to
         flushing. This is okay; the worst outcome is that the function would
         need to be compiled again later. Such a risk is already present,
         since V8 doesn't keep IsCompiledScopes for every compiled function in
         a background-deserialized script.
      B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
         compilation. This is also okay; the merge completion logic on the
         main thread will just keep this lazily compiled data rather than
         inserting compiled data from the newly deserialized object graph.
      C. SharedFunctionInfos can be cleared from the Script's weak array if
         they are no longer referenced. This is mostly okay, because any
         SharedFunctionInfo that is needed by the background merge is strongly
         referenced and therefore can't be cleared. The only problem arises if
         the top-level SharedFunctionInfo gets cleared, so the merge task must
         deliberately keep a reference to that one.
      D. SharedFunctionInfos can be created if they are needed due to lazy
         compilation of a parent function. This change is somewhat troublesome
         because it invalidates the background thread's work and requires a
         re-traversal on the main thread to update any pointers that should
         point to this lazily compiled SharedFunctionInfo.
      
      At a high level, this change implements three previously unimplemented
      functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
      
      - BackgroundDeserializeTask::SourceTextAvailable, run on the main
        thread, checks whether there is a matching Script in the Isolate
        compilation cache which doesn't already have a top-level
        SharedFunctionInfo. If so, it saves that Script in a persistent
        handle.
      - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
        whether the persistent handle from the first step exists (a fast
        operation which can be called from any thread).
      - BackgroundDeserializeTask::MergeWithExistingScript, run on a
        background thread, performs step 3 of the merge described above and
        generates lists of persistent data describing how the main thread can
        complete the merge.
      - BackgroundDeserializeTask::Finish is updated to perform the merge
        steps 1 and 2 listed above, as well as a possible re-traversal of the
        graph if required due to newly created SharedFunctionInfos in the old
        Script.
      
      The merge logic has nothing to do with deserialization, and indeed I
      hope to reuse it for background compilation tasks as well, so it is all
      contained within a new class BackgroundMergeTask (in compiler.h,cc). It
      uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
      the object visitation that updates pointers to SharedFunctionInfos.
      
      [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
      
      Bug: v8:12808
      Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#81941}
      e895b7af
  9. 24 Jul, 2022 1 commit
  10. 22 Jul, 2022 1 commit
  11. 18 Jul, 2022 1 commit
  12. 23 Jun, 2022 2 commits
  13. 22 Jun, 2022 1 commit
    • Luis Fernando Pardo Sixtos's avatar
      [shared-struct] Shared Array Initial prototype · afb26623
      Luis Fernando Pardo Sixtos authored
      Initial implementation for concurrent shared arrays. Current implementation exposes a `SharedArray` constructor, but its syntax might
      change in the future.
      
      Shared arrays can be shared across Isolates, have a fixed size, have no
      prototype, have no constructor, and can only store primitives, shared structs and other shared arrays. With this CL shared structs are also allowed to store shared arrays.
      
      The Backing storage for the SharedArrays is a `FixedArrayBase`. This CL introdces a new ElementKind: `SHARED_ARRAY_ELEMENTS`. The new kind should match the overall functionality of the `PACKED_SEALED_ELEMENTS` kind, but having it as standalone kind allows for easier branching in CSA and turbofan code.
      
      Bug: v8:12547
      Change-Id: I054a04624d4cf1f37bc26ae4b92b6fe33408538a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585353Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81285}
      afb26623
  14. 20 Jun, 2022 1 commit
  15. 14 Jun, 2022 1 commit
  16. 10 Jun, 2022 2 commits
  17. 08 Jun, 2022 1 commit
  18. 31 May, 2022 1 commit
  19. 25 May, 2022 1 commit
  20. 19 May, 2022 1 commit
  21. 17 May, 2022 2 commits
  22. 13 May, 2022 1 commit
  23. 06 May, 2022 1 commit
  24. 03 May, 2022 2 commits
  25. 13 Apr, 2022 1 commit
  26. 06 Apr, 2022 1 commit
  27. 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
  28. 25 Mar, 2022 2 commits
  29. 24 Mar, 2022 2 commits
    • Igor Sheludko's avatar
      [runtime] Fix handling of interceptors · 0981e91a
      Igor Sheludko authored
      Bug: chromium:1309225
      Change-Id: Ifd62639a2aa18b633e7cf36632677ee16c977afd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79613}
      0981e91a
    • 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
  30. 14 Mar, 2022 1 commit
  31. 25 Feb, 2022 1 commit
  32. 23 Feb, 2022 1 commit