1. 01 Aug, 2022 1 commit
  2. 19 Jul, 2022 2 commits
  3. 15 Jul, 2022 1 commit
  4. 14 Jul, 2022 1 commit
  5. 23 Jun, 2022 1 commit
  6. 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
  7. 20 Jun, 2022 1 commit
  8. 10 Jun, 2022 1 commit
  9. 13 May, 2022 1 commit
  10. 08 Apr, 2022 1 commit
  11. 07 Apr, 2022 1 commit
  12. 24 Mar, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Hold on to promises weakly from the debugger's promise stack. · 3eb6b7ac
      Benedikt Meurer authored
      The debugger maintains a stack of promises used for catch prediction
      with promise builtins and async functions. Previously this stack would
      hold on to the individual promises strongly, and subtle bugs that lead
      to not properly cleaning up the stack in some corner cases would often
      lead to significant memory issues (e.g. leaking whole iframes).
      
      This refactors the PromiseOnStack to be
      
        (a) on the V8 heap, rather than allocating C++ structs with global
            handles pointing to the promises, and
        (b) hold on to the promises only weakly.
      
      While this will not guarantee proper promise stack management, it will
      at least ensure that edge cases don't lead to catastrophic (debugger
      only) leaks.
      
      Bug: chromium:1292063
      Change-Id: I9c293ca2032de3a59e1e9624f132d37187805567
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545176
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79594}
      3eb6b7ac
  13. 14 Mar, 2022 1 commit
  14. 26 Jan, 2022 1 commit
  15. 13 Jan, 2022 1 commit
    • Jakob Gruber's avatar
      [maps] Lock map_updater_access in CompleteInobjectSlackTracking · 4b8d0489
      Jakob Gruber authored
      CompleteInobjectSlackTracking potentially shrinks multiple maps, and
      the relation between these maps should be preserved in a concurrent
      environment. Thus it is not enough to make each modification
      atomically, but all related map modifications must be within a
      critical section.
      
      We do this by locking the map_updater_access mutex
      CompleteInobjectSlackTracking, and hence moving the function to the
      MapUpdater class.
      
      Bug: chromium:1274445,v8:7990
      Change-Id: If99bb8b55e03180128ee397d845fa4c269c4241e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379819Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78597}
      4b8d0489
  16. 30 Nov, 2021 1 commit
  17. 24 Nov, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Internal representation for function references · f60132e9
      Manos Koukoutos authored
      Design doc: bit.ly/3jEVgzz
      
      We separate the internal representation of function references in Wasm
      from their JSFunction-based (external) representation. This improves
      performance of call_ref by requiring less indirections to load the
      context and call target from a function reference. In the boundary
      between wasm and JS/the C API, we add transformations between the two
      representations.
      
      Detailed changes:
      - Introduce WasmInternalFunction, containing fields required by
        call_ref, as well as a reference to the corresponding
        WasmExternalFunction. Add a reference to the WasmInternalFunction in
        WasmFunctionData. The {WasmInternalFunction::FromExternal} helper
        extracts the internal out of an external function.
      - Change {WasmInstanceObject::external_functions()} to internal
        functions.
      - Change wasm function tables to contain internal functions.
      - Change the following code to use internal functions:
        - call_ref in liftoff and Turbofan
        - function type checks in liftoff and Turbofan
        - CallRefIC and GenericJSToWasmWrapper builtins
        - {InitExprInterface::RefFunc}
        - module-compiler.cc in {ProcessTypeFeedback}
        - In module-instantiate.cc, in function-rtt creation.
      - Add transformations between internal and external functions in:
        - WasmWrapperGraphBuilder::{ToJS, BuildUnpackObjectWrapper, FromJS,
          BuildJSToJSWrapper}.
        - debug-wasm-objects.cc in {FunctionProxy::Get},
          {WasmValueObject::New} and {AddWasmTableObjectInternalProperties}.
        - runtime-wasm.cc in ReplaceWrapper
        - the C and JS APIs
        - module-instantiate.cc, in import and export processing, as well as
          {InitializeIndirectFunctionTables}
        - WasmTableObject::{IsValidElement, SetFunctionTableEntry}
        - {WasmGlobalObject::SetFuncRef}
      - Simplify body descriptors of WasmExternalFunction variants.
      - Adjust tests.
      
      Bug: v8:11510
      
      Change-Id: I8377f46f55c3771391ae1c5c8201a83854ee7878
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277878Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78068}
      f60132e9
  18. 05 Nov, 2021 1 commit
  19. 03 Nov, 2021 2 commits
    • Nico Hartmann's avatar
      Revert "Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"" · 6a3dc05f
      Nico Hartmann authored
      This reverts commit a3480b55.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview
      
      Original change's description:
      > Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"
      >
      > This is a reland of 7366f6e2
      >
      > The test that failed after the initial commit was just flaky and has
      > been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
      >
      > Original change's description:
      > > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
      > >
      > > Torque currently generates constants like kStartOfWeakFieldsOffset and
      > > kEndOfStrongFieldsOffset, which can be used when writing custom
      > > BodyDescriptors. However, these offsets have some potentially confusing
      > > behaviors:
      > >
      > > * They don't take inheritance into account and describe only the fields
      > >   defined by the current class itself, so there might be (for example)
      > >   strong fields before kStartOfStrongFieldsOffset if they were defined
      > >   by a superclass.
      > > * kStartOfWeakFieldsOffset points to the first field defined in Torque
      > >   using the keyword `weak`, which indicates fields with *custom*
      > >   weakness semantics (those that should be visited with
      > >   IterateCustomWeakPointers), not those that may contain standard weak
      > >   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
      > >   like to also rename `weak` to `@customWeak`.)
      > >
      > > Given that these constants have very low usage and somewhat bizarre
      > > semantics, I propose that we remove them. This change does so, and
      > > updates the existing usages to either define the required constants
      > > directly in C++ or not use them. I know that defining these constants in
      > > C++ is more brittle, but I think that brittle and clear is better than
      > > automatic and incomprehensible.
      > >
      > > Bug: v8:7793
      > > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > > Cr-Commit-Position: refs/heads/main@{#77411}
      >
      > Bug: v8:7793
      > Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77688}
      
      Bug: v8:7793
      Change-Id: I7b9667268901b7aef85a95832d40860056e61050
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77689}
      6a3dc05f
    • Seth Brenith's avatar
      Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · a3480b55
      Seth Brenith authored
      This is a reland of 7366f6e2
      
      The test that failed after the initial commit was just flaky and has
      been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
      
      Original change's description:
      > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
      >
      > Torque currently generates constants like kStartOfWeakFieldsOffset and
      > kEndOfStrongFieldsOffset, which can be used when writing custom
      > BodyDescriptors. However, these offsets have some potentially confusing
      > behaviors:
      >
      > * They don't take inheritance into account and describe only the fields
      >   defined by the current class itself, so there might be (for example)
      >   strong fields before kStartOfStrongFieldsOffset if they were defined
      >   by a superclass.
      > * kStartOfWeakFieldsOffset points to the first field defined in Torque
      >   using the keyword `weak`, which indicates fields with *custom*
      >   weakness semantics (those that should be visited with
      >   IterateCustomWeakPointers), not those that may contain standard weak
      >   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
      >   like to also rename `weak` to `@customWeak`.)
      >
      > Given that these constants have very low usage and somewhat bizarre
      > semantics, I propose that we remove them. This change does so, and
      > updates the existing usages to either define the required constants
      > directly in C++ or not use them. I know that defining these constants in
      > C++ is more brittle, but I think that brittle and clear is better than
      > automatic and incomprehensible.
      >
      > Bug: v8:7793
      > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77411}
      
      Bug: v8:7793
      Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77688}
      a3480b55
  20. 27 Oct, 2021 1 commit
  21. 15 Oct, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · 6025b260
      Leszek Swirski authored
      This reverts commit 7366f6e2.
      
      Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties
      
      Original change's description:
      > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
      >
      > Torque currently generates constants like kStartOfWeakFieldsOffset and
      > kEndOfStrongFieldsOffset, which can be used when writing custom
      > BodyDescriptors. However, these offsets have some potentially confusing
      > behaviors:
      >
      > * They don't take inheritance into account and describe only the fields
      >   defined by the current class itself, so there might be (for example)
      >   strong fields before kStartOfStrongFieldsOffset if they were defined
      >   by a superclass.
      > * kStartOfWeakFieldsOffset points to the first field defined in Torque
      >   using the keyword `weak`, which indicates fields with *custom*
      >   weakness semantics (those that should be visited with
      >   IterateCustomWeakPointers), not those that may contain standard weak
      >   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
      >   like to also rename `weak` to `@customWeak`.)
      >
      > Given that these constants have very low usage and somewhat bizarre
      > semantics, I propose that we remove them. This change does so, and
      > updates the existing usages to either define the required constants
      > directly in C++ or not use them. I know that defining these constants in
      > C++ is more brittle, but I think that brittle and clear is better than
      > automatic and incomprehensible.
      >
      > Bug: v8:7793
      > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/main@{#77411}
      
      Bug: v8:7793
      Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      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@{#77415}
      6025b260
    • Seth Brenith's avatar
      [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants · 7366f6e2
      Seth Brenith authored
      Torque currently generates constants like kStartOfWeakFieldsOffset and
      kEndOfStrongFieldsOffset, which can be used when writing custom
      BodyDescriptors. However, these offsets have some potentially confusing
      behaviors:
      
      * They don't take inheritance into account and describe only the fields
        defined by the current class itself, so there might be (for example)
        strong fields before kStartOfStrongFieldsOffset if they were defined
        by a superclass.
      * kStartOfWeakFieldsOffset points to the first field defined in Torque
        using the keyword `weak`, which indicates fields with *custom*
        weakness semantics (those that should be visited with
        IterateCustomWeakPointers), not those that may contain standard weak
        pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
        like to also rename `weak` to `@customWeak`.)
      
      Given that these constants have very low usage and somewhat bizarre
      semantics, I propose that we remove them. This change does so, and
      updates the existing usages to either define the required constants
      directly in C++ or not use them. I know that defining these constants in
      C++ is more brittle, but I think that brittle and clear is better than
      automatic and incomprehensible.
      
      Bug: v8:7793
      Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77411}
      7366f6e2
  22. 29 Sep, 2021 1 commit
  23. 16 Sep, 2021 1 commit
  24. 19 Aug, 2021 1 commit
    • Jakob Kummerow's avatar
      [wasm-gc] Store instance/element size directly on Map · 30f5140f
      Jakob Kummerow authored
      It must be possible to determine an object's size on the heap without
      relying on the presence of any other objects. Specifically, if an
      object and its WasmTypeInfo die at the same time, they can be swept
      in any order, and the sweeper may need to know their sizes.
      This patch solves the problem by repurposing two bytes in the Map,
      where WasmStructs can store their instance size, and WasmArrays can
      store their element size (which can be used to compute their size).
      
      Fixed: chromium:1240670
      Change-Id: Ib960fd0a409936aff1aef4daafed4c38b8497880
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106649
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76391}
      30f5140f
  25. 12 Aug, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Fix multiple races in Map::FindElementsKindTransitionedMap · 1b22e6fb
      Jakob Gruber authored
      The concurrent version was added recently in crrev.com/c/3085262.
      
      - UnusedPropertyFields requires the MapUpdater lock.
      - instance_descriptors must be read atomically on the bg thread.
      
      Finally, there appears to be a false positive report for the pattern:
      
       x = is_concurrent ? foo(kAcquireLoad) : foo();
      
      Here, clang emits code that executes both the atomic and nonatomic
      reads when is_concurrent is true. Needs more investigation.
      
      Bug: v8:7790, chromium:1239009
      Change-Id: I07d442e72cf0278f79f202a267e8d246f8abca1b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090341
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76261}
      1b22e6fb
  26. 11 Aug, 2021 3 commits
  27. 20 Jul, 2021 1 commit
    • Seth Brenith's avatar
      [cleanup] Use @generateCppClass on more classes · 334b94e1
      Seth Brenith authored
      Most Torque-defined extern classes already use @generateCppClass. As
      Nico pointed out in [1], it would be nice to convert the remaining
      classes and remove this option. This change converts most of those
      remaining classes. I know that the future of Torque-defined classes is a
      subject of some debate right now, but I think that it's worth doing a
      few mechanical changes to reduce the existing variety of options.
      
      Changes that don't exactly follow the usual pattern:
      1. BigIntBase, MutableBigInt: we can define these without a body, and
         then Torque treats them as "really external" rather than "kind of
         external, but with some Torque-generated parts".
      2. RegExpMatchInfo: moved its inline functions into a separate file,
         which the generated -tq.cc file requires.
      
      [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#
      
      Bug: v8:8952
      Change-Id: I84c7958a295caa0bab847683c05022e18c921cad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#75817}
      334b94e1
  28. 11 Jun, 2021 1 commit
  29. 26 May, 2021 1 commit
  30. 19 May, 2021 1 commit
  31. 10 May, 2021 1 commit
  32. 03 May, 2021 1 commit
  33. 29 Apr, 2021 1 commit
  34. 28 Apr, 2021 1 commit
  35. 22 Apr, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Support GetPropertyAccessInfo in a concurrent setting · 1277bb5c
      Jakob Gruber authored
      Until this CL, the JSHeapBroker::GetPropertyAccessInfo (GPAI) process
      was as follows:
      
       1. GPAI is called on the main thread (MT) during the serialization
          phase to create and cache PAIs.
       2. GPAI is called again from the background thread (BT); only cached
          PAIs from step 1 are usable.
      
      As part of concurrent inlining, the goal is to move GPAI fully to the
      background thread. This CL takes a major step in that direction by
      making GPAI itself callable from the BT without resorting solely to PAIs
      that were previously cached on the MT.
      
      There are two main reasons why GPAI previously had to run on the MT:
      
       a) Concurrent access to Maps and other heap objects.
       b) Serialization and creation of ObjectRefs for objects discovered
          during GPAI.
      
      This CL addresses only reason a) and leaves b) for future work. This
      is done by keeping the two-pass approach, s.t. the initial call of
      GPAI on the MT discovers and serializes objects. We then clear all
      cached PAIs. The second call of GPAI on the BT thus runs full logic in a
      concurrent setting.
      
      Once all relevant objects (= maps and prototypes) no longer require
      MT-serialization, reason b) is also addressed and the first pass can be
      removed.
      
      The new logic is implemented behind the runtime flag
      --turbo-concurrent-get-property-access-info (default true), intended
      to be removed in the future.
      
      Bug: v8:7790
      Change-Id: Idbdbfe091d7316529246a686bb6d71c2a0f06f8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2817793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74120}
      1277bb5c