1. 18 Feb, 2022 1 commit
  2. 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
  3. 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
  4. 01 Dec, 2021 1 commit
  5. 30 Nov, 2021 1 commit
  6. 22 Nov, 2021 2 commits
  7. 08 Nov, 2021 1 commit
    • Jakob Gruber's avatar
      [base] Extend SmallVector for use with Zone storage · 3a858a91
      Jakob Gruber authored
      This CL adds an Allocator to SmallVector to control how dynamic
      storage is managed. The default value uses the plain old C++
      std::allocator<T>, i.e. acts like malloc/free.
      
      For use with zone memory, one can pass a ZoneAllocator as follows:
      
        // Allocates in zone memory.
        base::SmallVector<int, kInitialSize, ZoneAllocator<int>>
          xs(ZoneAllocator<int>(zone));
      
      Note: this is a follow-up to crrev.com/c/3240823.
      
      Drive-by: hide the internal `reset` function. It doesn't free the
      dynamic backing store; that's a surprise and should not be exposed to
      external use.
      
      Change-Id: I1f92f184924541e2269493fb52c30f2fdec032be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257711
      Commit-Queue: Jakob 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@{#77755}
      3a858a91
  8. 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
  9. 13 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Reland "Implement a fake virtual memory cage mechanism" · 0aaec6ed
      Samuel Groß authored
      This is a reland of 1ea76c13
      
      Disabled the failing test on Fuchsia until its PageAllocator
      respects allocation hints.
      
      Original change's description:
      > Implement a fake virtual memory cage mechanism
      >
      > On operating systems where reserving virtual address space is expensive,
      > notably Windows pre 8.1, it is not possible to create a proper virtual
      > memory cage. In order to still be able to reference caged objects
      > through offsets from the cage base on these systems, this CL introduces
      > a fake cage mechanism. When the fake cage is used, most of the virtual
      > memory for the cage is not actually reserved. Instead, the cage's page
      > allocator simply relies on hints to the OS to obtain pages inside the
      > cage. This does, however, not provide the same security benefits as a
      > real cage as unrelated allocations might end up inside the cage.
      >
      > Bug: chromium:1218005
      > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
      > 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/+/3217200
      > Commit-Queue: Samuel Groß <saelo@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77367}
      
      Bug: chromium:1218005
      Change-Id: I2ed95d121db164679c38085115e8fa92690c057e
      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/+/3220151Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77378}
      0aaec6ed
  10. 12 Oct, 2021 2 commits
    • Deepti Gandluri's avatar
      Revert "Implement a fake virtual memory cage mechanism" · 1a0b993d
      Deepti Gandluri authored
      This reverts commit 1ea76c13.
      
      Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976?
      
      Original change's description:
      > Implement a fake virtual memory cage mechanism
      >
      > On operating systems where reserving virtual address space is expensive,
      > notably Windows pre 8.1, it is not possible to create a proper virtual
      > memory cage. In order to still be able to reference caged objects
      > through offsets from the cage base on these systems, this CL introduces
      > a fake cage mechanism. When the fake cage is used, most of the virtual
      > memory for the cage is not actually reserved. Instead, the cage's page
      > allocator simply relies on hints to the OS to obtain pages inside the
      > cage. This does, however, not provide the same security benefits as a
      > real cage as unrelated allocations might end up inside the cage.
      >
      > Bug: chromium:1218005
      > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
      > 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/+/3217200
      > Commit-Queue: Samuel Groß <saelo@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77367}
      
      Bug: chromium:1218005
      Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086
      Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77368}
      1a0b993d
    • Samuel Groß's avatar
      Implement a fake virtual memory cage mechanism · 1ea76c13
      Samuel Groß authored
      On operating systems where reserving virtual address space is expensive,
      notably Windows pre 8.1, it is not possible to create a proper virtual
      memory cage. In order to still be able to reference caged objects
      through offsets from the cage base on these systems, this CL introduces
      a fake cage mechanism. When the fake cage is used, most of the virtual
      memory for the cage is not actually reserved. Instead, the cage's page
      allocator simply relies on hints to the OS to obtain pages inside the
      cage. This does, however, not provide the same security benefits as a
      real cage as unrelated allocations might end up inside the cage.
      
      Bug: chromium:1218005
      Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
      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/+/3217200
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77367}
      1ea76c13
  11. 10 Aug, 2021 1 commit
  12. 06 Aug, 2021 1 commit
  13. 02 Aug, 2021 1 commit
  14. 02 Jul, 2021 2 commits
    • Zhi An Ng's avatar
      Revert "[build] Separate out inspector as a shared library" · 50fb0a2f
      Zhi An Ng authored
      This reverts commit 92bfb63c.
      
      Reason for revert: Broke build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/43249/overview
      
      Original change's description:
      > [build] Separate out inspector as a shared library
      >
      > This makes src/inspector:inspector into a v8_component producing a
      > shared library in component builds. To enable this, all of its exported
      > are now marked with V8_INSPECTOR_EXPORT.
      >
      > This also inverts the dependency between src/inspector:inspector and
      > :v8_base_without_compiler, and instead makes d8 and some tests depend on
      > inspector rather than getting it via v8.
      >
      > As a result, the no_check_targets exclusions list in .gn is reduced.
      >
      > Ultimately embedders like chromium should depend on :v8 and optionally
      > src/inspector:inspector, but to allow that transition to occur, this
      > renames :v8 to :v8_lib and introduces a new :v8 which depends on v8 and
      > inspector. Once all embedders have changed to reflect the new structure,
      > this part can be reverted.
      >
      > Bug: v8:11917
      > Change-Id: Ia8b15f07fb15acc5e1f111b1a80248def4285fd0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999088
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75532}
      
      Bug: v8:11917
      Change-Id: I0ed27ed95211d13b8b3438a8c0a42d577806c475
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003452
      Auto-Submit: Zhi An Ng <zhin@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/master@{#75533}
      50fb0a2f
    • Dan Elphick's avatar
      [build] Separate out inspector as a shared library · 92bfb63c
      Dan Elphick authored
      This makes src/inspector:inspector into a v8_component producing a
      shared library in component builds. To enable this, all of its exported
      are now marked with V8_INSPECTOR_EXPORT.
      
      This also inverts the dependency between src/inspector:inspector and
      :v8_base_without_compiler, and instead makes d8 and some tests depend on
      inspector rather than getting it via v8.
      
      As a result, the no_check_targets exclusions list in .gn is reduced.
      
      Ultimately embedders like chromium should depend on :v8 and optionally
      src/inspector:inspector, but to allow that transition to occur, this
      renames :v8 to :v8_lib and introduces a new :v8 which depends on v8 and
      inspector. Once all embedders have changed to reflect the new structure,
      this part can be reverted.
      
      Bug: v8:11917
      Change-Id: Ia8b15f07fb15acc5e1f111b1a80248def4285fd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999088Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75532}
      92bfb63c
  15. 10 May, 2021 1 commit
  16. 28 Apr, 2021 1 commit
  17. 18 Jan, 2021 1 commit
  18. 25 Nov, 2020 1 commit
  19. 20 Oct, 2020 1 commit
  20. 28 Sep, 2020 1 commit
  21. 24 Aug, 2020 1 commit
  22. 19 Jun, 2020 1 commit
    • Michael Lippautz's avatar
      Reland "cppgc: Properly clear (Weak)Peristent and WeakMember pointers" · 8bdce527
      Michael Lippautz authored
      This is a reland of e0c1a349
      
      The issue was passing SentinelPointer (== +1) through T*.
      
      The fix is disabling cfi unrelated cast diagnostic for the bottlenecks
      (Get()). This means that nullptr is treated the same as
      kSentinelPointer.
      
      The alternative would be a DCHECK that Get() does not return
      kSentinelPointer and adjusting all Member and Persistent logic that
      uses Get() to work on void*. This is quite intrusive as it involves
      Swap(), heterogeneous assignments, comparisons, etc.
      
      Original change's description:
      > cppgc: Properly clear (Weak)Peristent and WeakMember pointers
      >
      > The CL addresses two issues with (Weak)Persistent and WeakMember:
      > 1. (Weak)Persistent pointers are cleared on heap teardown. Before this
      >    CL the pointers would contain stale values which could lead to UAF.
      > 2. WeakPersistent and WeakMember are cleared using a combination of
      >    internal clearing methods and mutable fields which avoids the use
      >    of const_cast<>.
      >
      > Bug: chromium:1056170
      > Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Anton Bikineev <bikineev@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68394}
      
      Bug: chromium:1056170
      Change-Id: I3d74b43464c2973df1956f51b1419d755dd9f519
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250240Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68426}
      8bdce527
  23. 12 May, 2020 1 commit
    • Omer Katz's avatar
      heap,cppgc: Update StackState enum values · fff219bf
      Omer Katz authored
      This CL adds 2 new values to the EmbedderStackState enum with more
      explicit names. The old values are updated as aliases to the new
      values and marked as soon to be deprecated. This CL also moves the
      enum to v8-platform.h so that it can be reused by cppgc.
      
      Depracating individual values in an enum is supported by GCC only
      since version 6. Thus new macros were needed for the deprecation
      (which delegate to the existing macros when supported). GCC versions
      older than 6 are still used by the CQ bots.
      
      Bug: chromium:1056170
      Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67744}
      fff219bf
  24. 14 Jan, 2020 1 commit
  25. 21 Oct, 2019 1 commit
    • Clemens Backes's avatar
      Remove build support for gcc < 5 · 11e50bc3
      Clemens Backes authored
      We still set a lot of macros depending on specific gcc versions. All
      these old versions are unsupported by now anyways, so we can also just
      define these macros as 1.
      If this CL sticks for a while, we can start actually cleaning up all
      code relying on these macros, as most of them should be 1 now on all
      platforms.
      
      R=ulan@chromium.org
      
      Bug: v8:9810
      Change-Id: I2f9c55170091f8c263deeddfb7ff89e5b2a0bb12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862564Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64413}
      11e50bc3
  26. 16 Oct, 2019 1 commit
  27. 09 Oct, 2019 3 commits
  28. 19 Sep, 2019 1 commit
    • Jakob Gruber's avatar
      [build] Define V8_TARGET_OS_ and consider it in x64 codegen · 99d31b43
      Jakob Gruber authored
      This CL allows us to distinguish between the host- and target OS. The
      host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is
      defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN).
      
      V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn
      variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS
      (this determines fall-back behavior in V8; if it is not defined, we set
      V8_TARGET_OS_ to equal the equivalent V8_OS_ define).
      
      Besides adding the defines, this CL also adds logic to consider the
      target OS in codegen. Specifically, x64 builds now look at the
      V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This
      effectively makes cross-compilation to x64 Windows in mksnapshot
      possible.
      
      In future work, we could add similar support for cross-compiling to
      other platforms such as ia32 Windows.
      
      Bug: v8:9736,chromium:803591
      Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63892}
      99d31b43
  29. 18 Sep, 2019 1 commit
  30. 17 Sep, 2019 2 commits
    • Adam Klein's avatar
      Revert "Reland "Remove all custom CopyCharsUnsigned implementations"" · 24c35b92
      Adam Klein authored
      This reverts commits 9febc505
      (along with followup commit 60624b56).
      
      Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145
      
      nosnap bots may be deprecated, but as long as they're in LKGR
      we need to mind them.
      
      Original change's description:
      > Reland "Remove all custom CopyCharsUnsigned implementations"
      >
      > This is a reland of 5d8c4890
      >
      > Original change's description:
      > > Remove all custom CopyCharsUnsigned implementations
      > >
      > > It's unclear whether the custom implementation have any advantage over
      > > the standard library one's.
      > > Since we update our toolchain and standard library regularly, it might
      > > well be the case that the custom implementations are slower by now.
      > >
      > > Thus this CL removes all {CopyCharsUnsigned} implementations and
      > > implements {CopyChars} generically using {std::copy_n}.
      > >
      > > Note that this does not touch the {MemMove} and {MemCopy} functions
      > > yet, as we have seen regressions when trying to remove them before
      > > (https://crbug.com/v8/8675#c5).
      > >
      > > R=leszeks@chromium.org
      > >
      > > Bug: v8:9396
      > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63808}
      >
      > Bug: v8:9396
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63823}
      
      TBR=leszeks@chromium.org,clemensh@chromium.org
      
      Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63854}
      24c35b92
    • Clemens Hammacher's avatar
      Disallow nullptr arguments for {CopyChars} · 60624b56
      Clemens Hammacher authored
      This allows to remove special casing for the {count == 0} case, which
      was needed because {memmove} does not accept {nullptr} arguments even
      if the {count} is zero.
      
      R=leszeks@chromium.org
      
      Bug: v8:9396
      Change-Id: Iaef3cdbbffa74c2ba1c4e4501dafd943282cbcd9
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807366Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63838}
      60624b56
  31. 29 Aug, 2019 1 commit
  32. 08 Aug, 2019 1 commit
  33. 26 Jun, 2019 1 commit
  34. 17 Apr, 2019 1 commit