Skip to content

V
V8
Switch branch/tag
  1. 26 Apr, 2022 1 commit
  3. 25 Apr, 2022 2 commits
  5. 22 Apr, 2022 4 commits
  7. 20 Apr, 2022 2 commits
    • Benoît Lizé's avatar
      Reland "[builtins] Remap builtins on Linux" · 8d186bb4
      Benoît Lizé authored 
      Reason for reland: Fixed Fuchsia build.

Original change's description:
> [builtins] Remap builtins on Linux
>
> This is a CL similar to
> https://chromium-review.googlesource.com/c/v8/v8/+/3553006, but on Linux
> rather than macOS. The goal is to allow builtins to use short builtin
> calls without paying a memory cost, by remapping rather than copying
> them.
>
> However, while macOS has a system call making this easier, on Linux we
> don't have one on most kernels. There is the recently-introduced
> mremap(MREMAP_DONTUNMMAP), which is available in 5.7, but only works on
> anonymous mappings until 5.13, which is too recent for most Android
> devices.
>
> Instead, we open() the file containing the builtins, and mmap() it at
> the desired location.
>
> Change-Id: I4524f349948b8f48c4536cf392a1cd179662a6cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570426
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80022}

Change-Id: I0cc8cf510bd2cb8621130bea8406d79aa209948c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596164Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80049}
      8d186bb4
    • Victor Gomes's avatar
      [base] Lazily ensure ThreadList invariant · b127c341
      Victor Gomes authored 
      Since next() comes from ThreadedListTraits, the users of this class
can modify the list by modifying the next pointer. This however breaks
the invariant that `tail_` points to the last element of the list.

We ensure this invariant lazily. This should be _almost_ no effect
for users that do not manually modify the next pointer.

Change-Id: If46283ab4fc5036a81f353b25823b0fd39b3e232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578803Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80042}
      b127c341
  9. 19 Apr, 2022 3 commits
  11. 12 Apr, 2022 1 commit
    • Victor Gomes's avatar
      [maglev] Remove unnecessary CheckedSmiTag and CheckedSmiUntag · e96b8564
      Victor Gomes authored 
      We track untagged values through the InterpreterFrameState, that allows
us to re-use already emitted CheckedSmiUntag and elide CheckedSmiTag
whenever the next node wants the untagged value as input.

It uses LoadRegisterTaggedValue, LoadRegisterSmiUntaggedValue and
accumulator variants as helper in the graph builder.

Spilled values can now be untagged, since we currently do not
support stack slot re-use, we use a ZoneVector to keep track of
the stack slot representation.

We tag (lazily) any value that will be passed as input to a Phi node.

Bug: v8:7700

Change-Id: I34cb69c8f1fbeb6a8158a251a4dd2e114e894ea0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574559Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79939}
      e96b8564
  13. 11 Apr, 2022 1 commit
    • Jakob Gruber's avatar
      Reland "[osr] Add an install-by-offset mechanism" · b8473c52
      Jakob Gruber authored 
      This is a reland of commit 51b99213

Fixed in reland:
- bytecode_age was incorrectly still accessed as an int8 (instead
  of int16).
- age and osr state were incorrectly reset on ia32 (16-bit write
  instead of 32-bit).

Original change's description:
> [osr] Add an install-by-offset mechanism
>
> .. for concurrent OSR. There, the challenge is to hit the correct
> JumpLoop bytecode once compilation completes, since execution has
> moved on in the meantime.
>
> This CL adds a new mechanism to request installation at a specific
> bytecode offset. We add a new `osr_install_target` field to the
> BytecodeArray:
>
>   bitfield struct OSRUrgencyAndInstallTarget extends uint16 {
>     osr_urgency: uint32: 3 bit;
>     osr_install_target: uint32: 13 bit;
>   }
>
>   // [...]
>   osr_urgency_and_install_target: OSRUrgencyAndInstallTarget;
>   bytecode_age: uint16;  // Only 3 bits used.
>   // [...]
>
> Note urgency and install target are packed into one 16 bit field,
> we can thus merge both checks into one comparison within JumpLoop.
> Note also that these fields are adjacent to the bytecode age; we
> still reset both OSR state and age with a single (now 32-bit)
> store.
>
> The install target is the lowest 13 bits of the bytecode offset.
> When set, every reached JumpLoop will check `is this my offset?`,
> and if yes, jump into runtime to tier up.
>
> Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field.
>
> Bug: v8:12161
> Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79853}

Bug: v8:12161
Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79911}
      b8473c52
  15. 08 Apr, 2022 1 commit
  17. 07 Apr, 2022 2 commits
  19. 06 Apr, 2022 2 commits
  21. 05 Apr, 2022 1 commit
  23. 04 Apr, 2022 1 commit
  25. 01 Apr, 2022 2 commits
    • Benoit Lize's avatar
      [builtins] Remap embedded builtins into the heap on ARM64 macOS · da1a2d12
      Benoit Lize authored 
      For short builtin calls, the builtins are copied on the heap when they
cannot be put close enough to be in range of relative calls. This costs
memory, as the embedded builtins are part of the binary, and mapped from
the binary, and as a consequence shared with all running processes.

Rather than copying the memory, we can remap it at a different address,
avoiding the memory cost. This CL does that, on ARM64 macOS only for
now.

This saves at least ~1.4MiB of memory per V8 process. See below the
output of vmmap <PID>:

[...]
Memory Tag 255             7408308000-740833c000   [  208K   144K   144K     0K] r-x/rwx SM=ZER
Memory Tag 255             740833c000-7408340000   [   16K     0K     0K     0K] ---/rwx SM=ZER
Memory Tag 255             7408344000-7408348000   [   16K     0K     0K     0K] ---/rwx SM=ZER
Memory Tag 255             7408348000-740837c000   [  208K   144K   144K     0K] r-x/rwx SM=ZER
Memory Tag 255             740837c000-740fe80000   [123.0M     0K     0K     0K] ---/rwx SM=ZER
mapped file                740fe80000-740ffe4000   [ 1424K  1328K     0K     0K] r-x/rwx SM=COW          ...pp/Contents/Frameworks/Chromium Framework.framework/Versions/102.0.4958.0/Chromium Framework
Memory Tag 255             740ffe4000-7410000000   [  112K     0K     0K     0K] ---/rwx SM=ZER

The "208K" regions are 256kiB code pages, minus the header and guard
pages, meaning that they are code chunks. The mapped file are the
remapped builtins, showing that they aren't copied, but remapped from
the binary.

Bug: chromium:1298417
Change-Id: Ia30a43e671726d01450a7db0ecb7777b34763053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3553006Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79716}
      da1a2d12
    • Yuly Novikov's avatar
      Fix build with Windows 10 20348 SDK · ca2a787a
      Yuly Novikov authored 
      Bug: chromium:1292528
Change-Id: If4da2ec92afb7b4fe9942778eca385344b9b6409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563539
Auto-Submit: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79709}
      ca2a787a
  27. 21 Mar, 2022 1 commit
  29. 18 Mar, 2022 1 commit
    • Michael Lippautz's avatar
      Revert "cppgc: Rework prefinalizers" · f46c4858
      Michael Lippautz authored 
      This reverts commit cf25b3bc.

Reason for revert: https://crbug.com/1307471. TraceTrait must only be used during marking.

Original change's description:
> cppgc: Rework prefinalizers
>
> Move the check for whether an object is live or dead out of the
> prefinalizer trampoline. Moving it into the backend allows for
> inlining the check which avoids a call to the trampoline for live
> objects.
>
> On catapult benchmarks (e.g. cnn:2021, nytimes:2020), there's often
> ~2k finalizers registered. In order to avoid memory overhead in the
> range of a few KB, we store the fact whether the object points to the
> base object payload in the LSB of the pointer. For caged builds this
> is replaced with just storing the index into the cage for both object
> and base object payload.
>
> Locally saves around ~10% of atomic sweeping processing time which is
> in the order of .05ms.
>
> Bug: v8:12698
> Change-Id: I198205a6b1d57fc2df821ee4e73e53dc6f825ff5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497764
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79442}

Bug: v8:12698, chromium:1307471
Change-Id: I5c4e70d46cb99af66c77f0c013625b6af6c6eb8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535781
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79527}
      f46c4858
  31. 17 Mar, 2022 1 commit
  33. 16 Mar, 2022 1 commit
  35. 15 Mar, 2022 2 commits
  37. 14 Mar, 2022 1 commit
    • Milad Fa's avatar
      PPC: Use native x64 linux page size on the simulator · e35a3a77
      Milad Fa authored 
      Running `OS::AllocatePageSize()` on PPC simulator (which
runs on x64 Linux) will make a `sysconf(_SC_PAGESIZE)` call
which returns the native x64 Linux page size and not the PPC
specific page size.

This can cause a problem if used along side the current value of
`kPageSizeBits` which is set to use PPC value even on Sim.
As an example a newly added DHCECK under https://crrev.com/c/3497363
was failing on PPC Sim as a call to `AllocatableMemoryInDataPage`
was being made which used kPageSizeBits on Sim.

Meanwhile another function was using the `page_size_bits` value which
gets set by _SC_PAGESIZE. The mismatch caused an incorrect final value
being generated which failed the DCHECK.

Change-Id: Iaf2d9cff16bbe5f6be5f3ec6a13b99be94776f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3519758Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#79465}
      e35a3a77
  39. 10 Mar, 2022 4 commits
  41. 07 Mar, 2022 1 commit
  43. 03 Mar, 2022 1 commit
  45. 25 Feb, 2022 1 commit
  47. 24 Feb, 2022 2 commits
  49. 22 Feb, 2022 1 commit