1. 06 Apr, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "[string] Non-transitioning shared strings" · c35ca2b7
      Leszek Swirski authored
      This reverts commit 8ba60b7a.
      
      Reason for revert: code_serializer failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/38940/overview
      
      Original change's description:
      > [string] Non-transitioning shared strings
      >
      > Instead of transitioning shared strings to ThinString on
      > internalization, use a forwarding table to the internalized string and
      > store the index into the forwarding table in the string's hash field.
      >
      > This way we don't need to handle concurrent string transitions that
      > modify the underlying string data.
      >
      > During stop-the-world GC, live strings in the forwarding table are
      > migrated to regular ThinStrings.
      >
      > Bug: v8:12007
      > Change-Id: I6c6f3d41c6f644e0aaeafbf25ecec5ce0aa0d2d8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536647
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Jakob Linke <jgruber@chromium.org>
      > Reviewed-by: Shu-yu Guo <syg@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79801}
      
      Bug: v8:12007
      Change-Id: I740904f3edfc395331f06c7218e89476b06b0563
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574543
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#79810}
      c35ca2b7
    • Patrick Thier's avatar
      [string] Non-transitioning shared strings · 8ba60b7a
      Patrick Thier authored
      Instead of transitioning shared strings to ThinString on
      internalization, use a forwarding table to the internalized string and
      store the index into the forwarding table in the string's hash field.
      
      This way we don't need to handle concurrent string transitions that
      modify the underlying string data.
      
      During stop-the-world GC, live strings in the forwarding table are
      migrated to regular ThinStrings.
      
      Bug: v8:12007
      Change-Id: I6c6f3d41c6f644e0aaeafbf25ecec5ce0aa0d2d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536647Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79801}
      8ba60b7a
  2. 23 Feb, 2022 1 commit
  3. 18 Feb, 2022 1 commit
    • Michael Achenbach's avatar
      Revert "[shared-struct] Prototype JS shared structs" · c1078b5e
      Michael Achenbach authored
      This reverts commit 1025bf26.
      
      Reason for revert: https://crbug.com/v8/12645
      
      Original change's description:
      > [shared-struct] Prototype JS shared structs
      >
      > Unlike the Stage 1 proposal, for simplicity the prototype does not add
      > any new syntax, instead opting for exposing a SharedStructType
      > constructor which takes an array of field names. This type constructor
      > returns constructors for shared structs.
      >
      > Shared structs can be shared across Isolates, are fixed layout, have no
      > prototype, have no .constructor, and can only store primitives and
      > other shared structs.
      >
      > The initial prototype does not have TurboFan support.
      >
      > Bug: v8:12547
      > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Shu-yu Guo <syg@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79156}
      
      Bug: v8:12547
      Change-Id: I44f2b8bb7487b4d39ba1282585e0b2282501230f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474676
      Auto-Submit: Michael Achenbach <machenbach@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Michael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79170}
      c1078b5e
  4. 17 Feb, 2022 1 commit
  5. 20 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Implement GC for the external pointer table · 4a3e41c5
      Samuel Groß authored
      The external pointer table is now managed by the GC, which marks entries
      that are alive during major GC, then sweeps the table afterwards to free
      all dead entries and build a free list from them. For now, only major GCs
      are supported, Scavenger GCs do not interact with the external pointer table.
      
      In more detail, garbage collection of the external pointer table works
      as follows:
      
      1. The external pointer table now reserves a large region of virtual
         address space for its backing buffer and is then never reallocated,
         only grown in place until the maximum size is reached.
      2. When the GC's marking visitor marks a HeapObject with an external
         pointer as alive, it also marks the corresponding external pointer
         table entry as alive. This can happen on a background thread.
      3. For that, it uses the MSB of each entry in the table to indicate
         whether the entry has been marked or not. This works because the MSB
         is always cleared during the AND-based type check performed when
         accessing an external pointer.
      4. After marking, the external pointer table is swept while the mutator
         is stopped. This builds an inline, singly-linked freelist of all
         newly-dead and previously-free entries.
      5. When allocating an entry from the table, the first entry on the
         freelist is used. If the freelist is empty, the table grows,
         populating the freelist with the new entries.
      6. Every newly-allocated entry is marked as alive, and every store to an
         existing entry also automatically marks that entry as alive (by also
         setting the MSB). This simplifies the design of the table GC with
         regards to concurrency (See ExternalPointerTable::Mark).
      
      Bug: v8:10391
      Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359625Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78708}
      4a3e41c5
  6. 17 Jan, 2022 1 commit
  7. 04 Jan, 2022 1 commit
  8. 16 Dec, 2021 1 commit
  9. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  10. 02 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Use CagedPointers for ArrayBuffer backing stores · 42ed4928
      Samuel Groß authored
      This CL turns references to ArrayBuffer backing stores from
      JSArrayBuffers, JSTypedArrays, and JSDataViews into CagedPointers
      when those are enabled.
      
      CagedPointers cannot generally represent nullptr, as NULL usually lies
      outside the cage. As such, nullptr backing stores are replaced with a
      special empty backing store value, which, in the current implementation,
      points to the end of the cage, right in front of the trailing guard
      regions. Due to this, it is no longer correct to compare a backing store
      pointer against nullptr.
      
      Bug: chromium:1218005
      Change-Id: I4a6c7a82aabb4debcb6bb2babe4035ba2da8e79f
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244419
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78218}
      42ed4928
  11. 24 Nov, 2021 1 commit
  12. 23 Nov, 2021 2 commits
  13. 22 Nov, 2021 3 commits
  14. 17 Nov, 2021 1 commit
    • Tobias Tebbi's avatar
      [builtins] add Torque fast-path for String.prototype.localeCompare · 6181ce59
      Tobias Tebbi authored
      This fast path works for ASCII-only strings and is similar to the
      existing fast-path in C++. Important differences:
      - The locale check is done at Turbofan optimization time instead of
        at runtime
      - Use tables of size 256 instead of 128 to save a bounds-check when
        handling one-byte strings.
      - It first performs an equality check that's optimized for detecting
        inequality quickly by comparing the strings from both ends. If the
        equality check succeeds, we are done. Otherwise chances are high
        that the strings differ according to collation level L1 already.
        Therefore, we first do an L1 check and perform the L3 check
        only when L1 didn't find a difference. This is based on the assumption
        that few strings are identical except for different capitalization.
      - Use the Torque version of string flattening instead of the runtime
        version.
      
      Bug: v8:12196
      Change-Id: I2d043c1138846783f6d567b736d34063ba9301e5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268465Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77946}
      6181ce59
  15. 09 Nov, 2021 1 commit
  16. 08 Nov, 2021 1 commit
  17. 05 Nov, 2021 1 commit
  18. 03 Nov, 2021 1 commit
  19. 29 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Introduce CagedPointer · afd15549
      Samuel Groß authored
      A CagedPointer is guaranteed to point into the Virtual Memory Cage and
      will for example be used for ArrayBuffer backing stores when the heap
      sandbox is enabled. In the current implementation, CagedPointers are
      stored as offsets from the cage base, shifted to the left. Because the
      cage base address is usually available in a register, accessing a
      CagedPointer is very efficient, requiring only an additional shift and
      add operation.
      
      Bug: chromium:1218005
      Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123417Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77614}
      afd15549
  20. 27 Oct, 2021 1 commit
  21. 19 Oct, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Compact codegen for large character classes · 8bbb44e5
      Jakob Gruber authored
      Large character classes may easily be created when unicode
      properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
      expanded internally into character classes that consist of hundreds
      of character ranges. Previously to this CL, we'd emit branching code
      for each of these ranges, leading to very large regexp code objects.
      
      This CL adds a new codegen mode for large character classes (where
      'large' currently means > 16 ranges). Instead of emitting branching
      code inline, the ranges are written into a ByteArray and we call into
      the C function IsCharacterInRangeArray for the actual branching logic.
      The ByteArray is smaller than emitted code and is deduplicated if the
      same character class is matched repeatedly in the same pattern.
      
      Note this mode is *not* implemented for the interpreter, since we
      currently don't have a constant pool for irregexp bytecode, and thus
      cannot reference ByteArrays.
      
      Bug: v8:11069
      Change-Id: I2d728e42d85114b796c637f791848731a104cd54
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77463}
      8bbb44e5
  22. 11 Oct, 2021 1 commit
  23. 01 Oct, 2021 1 commit
  24. 23 Sep, 2021 1 commit
  25. 15 Sep, 2021 1 commit
  26. 14 Sep, 2021 1 commit
  27. 07 Sep, 2021 1 commit
  28. 03 Sep, 2021 1 commit
  29. 01 Sep, 2021 1 commit
  30. 16 Aug, 2021 1 commit
  31. 10 Aug, 2021 1 commit
  32. 04 Aug, 2021 1 commit
  33. 22 Jul, 2021 2 commits
  34. 07 Jul, 2021 1 commit
  35. 28 Jun, 2021 1 commit