Skip to content

V
V8
Switch branch/tag
  1. 24 Feb, 2022 1 commit
    • Clemens Backes's avatar
      Fail earlier on FreePages · 205fb295
      Clemens Backes authored 
      {FreePages} is never expected to fail, and each caller wraps the call in
a CHECK macro. In order to learn more about failures, this CL moves the
CHECK inside of {::FreePages}, to fail whenever the {PageAllocator}
fails to free pages.

As a next step, I'll audit our {PageAllocator} implementations to ensure
that none of them return {false} for {FreePages}. Note that this is
already the case for the gin platform (chromium).

R=mlippautz@chromium.org

Bug: v8:12656, chromium:1299735
Change-Id: Ib61be6cc8da0110ead2db1ad005728bd061e0243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484321Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79248}
      205fb295
  3. 23 Feb, 2022 1 commit
    • Jakob Gruber's avatar
      [safepoints] Various refactors · c7e47c30
      Jakob Gruber authored 
      A collection of smallish cleanups and improvements for safepoints.

Maintainability:
- The class names were not very clear; move Safepoint inside
  SafepointTableBuilder to clarify that this wrapper class is used
  during codegen.
- Rename DefinePointerSlot/DefineRegister to
  DefineTaggedStackSlot/DefineTaggedRegister for clarity.
- Use named constants instead of -1.
- DefineTaggedRegister has no connection to kNoDeoptIndex, remove
  the DCHECK and comment.
- Remove the unused kNumSafepointRegisters constant + other dead code.
- Small clarifications in CommonFrame::IterateCompiledFrame.
- Rename has_safepoint_info to uses_safepoint_table and refactor s.t.
  `stack_slots` can be used when `uses_safepoint_table == false`. In
  this case it just returns 0.

Perf:
- During codegen, represent stack slots as a growable bit vector
  instead of a list of int indices. Extend GrowableBitVector
  functionality to support the above.
- Track the minimum index instead of iterating all stack slots in
  all safepoints before encoding.

Bug: v8:7700
Change-Id: If409bc42c825d47fc0074fce51e3b963fd080806
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483659Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79233}
      c7e47c30
  5. 14 Feb, 2022 1 commit
    • Leszek Swirski's avatar
      [utils] Move BitVector's iterator to STL-like interface. · 59ea4881
      Leszek Swirski authored 
      Replace the Advance/Done methods on BitVector::Iterator with
STL-compatible operator overloads, and add begin/end methods to
BitVector itself, so that BitVectors can be iterated with ranged for
loops.

As a drive-by cleanup, make GrowableBitVector hold the BitVector by
value (to avoid needing to allocate one for empty iteration), and remove
its unused (and inefficient) Union method.

Change-Id: Idcd34e26bfb087e3ec8297b4a769a51bfab4b6e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455803Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79071}
      59ea4881
  7. 26 Jan, 2022 1 commit
    • Igor Sheludko's avatar
      [ext-code-space] Fix CodeRange allocation logic · 695afbff
      Igor Sheludko authored 
      1) when generating short builtin calls/jumps assemblers should use the
   offset from the CodeRange base rather than the start of the code
   range reservation because otherwise it's not guaranteed that the
   PC-relative offset will fit into architecture's constraints.
   The code range reservation start could be different from the code
   range base in the following cases:
     * when the "base bias size" is non-zero (on Windows 64),
     * when we ended up over-reserving the address space for the code
       range, which happens as a last resort to fulfil the CodeRange
       alignment requirements.
   See the VirtualMemoryCage description for details.

Drive-by fixes:
2) in case of over-reserving address space for external code range,
   the pre-calculated hint for where the remapped embedded builtins
   should be copied to was outside of the allocatable CodeRange region
   and thus useless. The fix is to use the allocatable region instead
   of the reservation region when calculating the hint.
3) when allocating CodeRange with zero base bias size we can create
   the VirtualMemory reservation from the first attempt simply by
   passing the required base alignment to the VirtualMemory
   constructor.

Bug: v8:11880, chromium:1290591
Change-Id: If341418947e2170d967e22b38bcc371594939c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78772}
      695afbff
  9. 21 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Share liveness across straight-line bytecode · 4465c321
      Leszek Swirski authored 
      Straight-line bytecode with exactly one "next" bytecode (i.e. everything
that can't affect control flow) will always have the same "out" liveness
as the next bytecode's "in" liveness. For those cases, we can save a bit
of time and memory by aliasing the pointers between the bytecode's out
liveness and the next bytecode's in liveness, and skipping copying
between them.

This is done by specializing the current liveness update on whether this
is the first pass (which will allocate and initialize the liveness
bitvectors) or an update pass (which will revisit loops to collect
liveness crossing over the back-edge, and propagate this liveness
through the loop bodies). On the first pass, we can delay allocation of
the out liveness until we know it needs to be union of multiple in
livenesses, and on the update pass we can skip it if it is an alias.

As a drive-by, tweak BitVector::CopyFrom to require copying from a
vector with the same size (same as Union or Intersect), and move the
only different sized vector use (in Resize) to be inline.

Change-Id: Iad1b2e1b927a37ad925ef68e2a224152aaa2ba18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350452
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78425}
      4465c321
  11. 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
  13. 06 Dec, 2021 1 commit
  15. 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
  17. 11 Nov, 2021 1 commit
  19. 04 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored 
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
the canonical id for these jobs.

This has several consequences:

  * We no longer split enqueing a job and registering a SFI with that
    job. We did this previously because we could not allocate SFIs in
    the Parser -- now with LocalHeap we can, so we do.
  * We remove the separate Job vector, and make the SFI IdentityMap
    hold pointers to Jobs directly. This requires a small amount of
    extra care to deallocate Jobs when removing them from the map,
    but it means not having to allocate new global handles for jobs.
  * The SFI is passed into the BackgroundCompileTask instead of the
    script, so our task finalization doesn't need the SFI anymore.
  * We no longer need to iterate ParallelTasks after compiling (to
    register SFIs), so we can get rid of ParallelTasks entirely and
    access the dispatcher directly from the parser.

There are a few drive-bys since we're touching this code:

  * Jobs are move to have a "state" variable rather than a collection
    of bools, for stricter DCHECKing.
  * There's no longer a set of "currently running" jobs, since this
    was only used to check if a job is running, we can instead inspect
    the job's state directly.
  * s/LazyCompilerDispatcher/LazyCompileDispatcher/g

Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
  21. 19 Oct, 2021 2 commits
  23. 18 Oct, 2021 3 commits
  25. 14 Oct, 2021 1 commit
  27. 07 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Add PageInitializationMode enum for the BoundedPageAllocator · 18c37d32
      Samuel Groß authored 
      Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the
behavior of the BoundedPageAllocator changes from simply making freed
pages inaccessible to decommitting them, which guarantees that they will
be zero-initialized after the next allocation. As this seems to cause
some performance regressions on Mac, this CL introduces a new enum that
specifies how the allocator should behave:
kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted
during FreePages() and ReleasePages() and thus guarantees
zero-initialization during AllocPages().
kAllocatedPagesCanBeUninitialized only causes the pages to be made
inaccessible, and so does not generally guarantee zero-initialization
for AllocPages().

Finally, this CL also removes some dead code in allocation.cc.

Bug: chromium:1257089
Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77285}
      18c37d32
  29. 06 Oct, 2021 1 commit
  31. 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
  33. 17 Sep, 2021 1 commit
  35. 16 Sep, 2021 1 commit
  37. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored 
      This is a reland of d1b27019

Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  39. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored 
      This reverts commit d1b27019.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
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@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored 
      This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  41. 11 Aug, 2021 1 commit
  43. 03 Aug, 2021 1 commit
    • Bruce Dawson's avatar
      Remove windows.h from win32-headers.h · fb9e1299
      Bruce Dawson authored 
      Windows.h causes massive namespace pollution with its defining of many
macros, it adds to build times, it disables warnings, and it makes it
easier to write non-portable code.

This change removes windows.h from V8's win32-headers.h. It does this
by replicating the small number of typedefs that are needed and by
defining three "proxy" types that are the same size and layout. The
V8ToWindowsType functions are used to reinterpret_cast between the
types.

Prior to this change there were over 760 v8-related source files that
include windows.h. After this change there are 16.

Bug: chromium:796644
Change-Id: I89efeed47028faae72de2da4f1dae345d8d7746c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042215
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76064}
      fb9e1299
  45. 19 Jul, 2021 1 commit
  47. 08 Jul, 2021 2 commits
  49. 01 Jul, 2021 1 commit
  51. 24 Jun, 2021 3 commits
  53. 22 Jun, 2021 3 commits
  55. 18 Jun, 2021 2 commits
  57. 17 Jun, 2021 1 commit
  59. 10 Jun, 2021 1 commit