Skip to content

V
V8
Switch branch/tag
  1. 04 Jan, 2022 1 commit
    • Samuel Groß's avatar
      [base] Add VirtualAddressSpace::AllocateGuardRegion · 406d65d3
      Samuel Groß authored 
      Previously, guard regions were created by allocating pages with
PROT_NONE and relying on an allocation hint. This could fail however,
for example on Fuchsia (where it would allocate a VMO to back the guard
region) and possibly on Windows (where a placeholder mapping was
replaced by a "real" mapping).

Introducing an explicit VirtualAddressSpace::AllocateGuardRegion routine
now makes this operation more efficient and effectively guarantees that
it cannot fail if used correctly: in a regular subspace, there is no
need to allocate anything when creating guard regions since the address
space reservation backing the subspace is guaranteed to be inaccessible
when no pages are allocated in it.

Bug: chromium:1218005
Change-Id: I6945f17616b6b8dad47241af96d4cb1f660e8858
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/+/3366237Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78480}
      406d65d3
  3. 04 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Introduce VirtualAddressSpace interface · a7cb30b0
      Samuel Groß authored 
      This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.

The new interface is not yet stable and may change at any time without
deprecating the old version first.

Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
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/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
      a7cb30b0
  5. 01 Dec, 2021 1 commit
  7. 14 Oct, 2021 1 commit
  9. 23 Sep, 2021 1 commit
    • Anton Bikineev's avatar
      [zone] Provide a way to configure allocator for zone backings · e262e1cb
      Anton Bikineev authored 
      The CL provides a way for the embedder to hook in a special malloc-like
allocator that will be used for zone allocations.

An alternative approach would be to use weak functions with branches,
checking whether the functions were available at link-time. Those
branches could be optimized away with LTOs, so they would essentially
be free. However, the weak function approach is not portable (e.g.
there is no easy way to emulate it with msvc). The approach can be
revisited if indirect call turns out to be expensive (e.g. on hardware
with weak branch target predictors).

The CL is a prerequisite for running PCScan in the renderer process.

Bug: chromium:1249550
Change-Id: I221dcb2486c13e8e6e6761839ba391978319bde4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172760Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77012}
      e262e1cb
  11. 11 Aug, 2021 1 commit
  13. 07 Apr, 2021 1 commit
  15. 16 Mar, 2021 1 commit
  17. 12 Mar, 2021 1 commit
  19. 11 Mar, 2021 1 commit
  21. 10 Dec, 2020 1 commit
  23. 30 Oct, 2020 1 commit
  25. 19 Oct, 2020 1 commit
  27. 07 Oct, 2020 1 commit
    • Omer Katz's avatar
      cppgc, jobs: Update job priority · 4cb4a229
      Omer Katz authored 
      This CL aligns the library implementation with the blink implementation:
(*) Concurrent marking increases job priority if no concurrent progress
    is made in the last 50% of the expected marking duration.
(*) Concurrent sweeping increases job priority when calling
    FinishIfRunning (the library equivalent of blink's CompleteSweep).

Bug: chromium:1056170
Change-Id: Ice275cb90a7dd76bf4125f4338d9d80e5f576c58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431572
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70375}
      4cb4a229
  29. 06 Oct, 2020 2 commits
  31. 17 Sep, 2020 1 commit
  33. 02 Sep, 2020 1 commit
  35. 25 Aug, 2020 1 commit
  37. 13 Aug, 2020 1 commit
  39. 30 Jul, 2020 1 commit
    • Dan Elphick's avatar
      [platform] Add SharedMemory allocation and mapping · c1c38e19
      Dan Elphick authored 
      This adds new methods AllocateSharedPages, ReserveForSharedMemoryMapping
and CanAllocateSharedPages to v8::PageAllocator, which if overridden
allows the platform to declare that it supports allocation and remapping
of shared memory.

This interface is currently a work in progress so the new methods are
marked "INTERNAL ONLY" and they may change without being first
deprecated.

An implementation of PageAllocator is provided that can allocate and map
shared memory on Linux and Android, but no other platforms are yet
supported. While Windows is not supported the interface has been
designed to make this possible as AllocateSharedPages returns a
SharedMemory object that wraps the shared memory and provides its own
remap function. This should allow the SharedMemory object on windows to
contain a mapping a to hFileMappingObject as required by
MapViewOfFileEx.

Bug: v8:10454
Change-Id: I2e601d49ea14da44867a102c823fa4e341cf0dab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306789Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69154}
      c1c38e19
  41. 23 Jul, 2020 1 commit
  43. 20 Jul, 2020 1 commit
  45. 23 Jun, 2020 1 commit
  47. 27 Apr, 2020 1 commit
  49. 24 Apr, 2020 1 commit
  51. 17 Apr, 2020 1 commit
  53. 24 Jan, 2020 1 commit
  55. 08 Jan, 2020 1 commit
  57. 21 Oct, 2019 1 commit
  59. 14 Oct, 2019 1 commit
  61. 09 Oct, 2019 1 commit
    • Clemens Backes's avatar
      [api] Use C++14 [[deprecated]] attribute · 739bee71
      Clemens Backes authored 
      Since C++14, there is a spec'ed attribute for deprecation of methods,
functions, types, aliases or anything else.
This CL switches from the GCC __attribute__ to this standard attribute.
This allows to use the V8_DEPRECATED and V8_DEPRECATE_SOON macros on
anything where the standard attribute can be used (including {using}
statements that were not working before). It also avoids the need to
nest the whole declaration in the macro, making the code more readable.

R=adamk@chromium.org

Bug: v8:9810
Change-Id: I7adab7694af75423fb31ade2fc982dbf9c9bc699
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847361Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64174}
      739bee71
  63. 13 Aug, 2019 1 commit
  65. 08 Jul, 2019 1 commit
  67. 13 May, 2019 1 commit
  69. 19 Feb, 2019 1 commit
  71. 08 Feb, 2019 1 commit
  73. 14 Jan, 2019 1 commit
  75. 22 Oct, 2018 2 commits