1. 04 Apr, 2022 2 commits
  2. 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
    • Dominik Inführ's avatar
      [heap] Support safepoint->AssertActive() for shared isolates · 5bc471f4
      Dominik Inführ authored
      Lock mutex for shared isolate in global safepoints, such that e.g. the
      StringTable can use isolate->heap()->safepoint()->AssertActive() even
      for shared isolates.
      
      Bug: v8:11708, v8:12749
      Change-Id: I8d99203581dfa2d7225846e19fa981300f88589e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563138Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79715}
      5bc471f4
  3. 29 Mar, 2022 2 commits
  4. 28 Mar, 2022 1 commit
  5. 24 Mar, 2022 1 commit
    • Milad Fa's avatar
      PPC: Introduce Power10 prefixed instructions · d7966ecd
      Milad Fa authored
      P10 comes with prefixed instruction (2 x 4-byte instructions)
      which allow for using larger immediate values. `paddi` has
      been added in this CL which uses a 34-bit immediate.
      
      Prefixed instructions cannot cross 64-byte boundaries, i.e we cannot
      have the first 4-bytes on one side and the second 4-bytes emitted on
      the other side of the boundary. Therefore we need to align generated
      code to 64 bytes and emit a nop whenever the boundary is being crossed
      midway (check emit_prefix).
      
      Change-Id: I90e9953089214e15eeef0d70147ea5943fe05f45
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528993Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/main@{#79612}
      d7966ecd
  6. 23 Mar, 2022 1 commit
    • Leszek Swirski's avatar
      [snapshot] Guard against flushing when installing native IET · eec3f923
      Leszek Swirski authored
      CreateInterpreterDataForDeserializedCode checks for bytecode, copies the
      InterpreterEntryTrampoline, and installs that and the bytecode on
      InterpreterData. However, the bytecode can be flushed when the IET is
      copied, which results in a failure to read it afterward.
      
      Add an IsCompiledScope to guard against this.
      
      As a drive-by, guard against baseline code being installed on the
      function. This shouldn't happen in normal execution, but could
      theoretically happen with some extra support for --always-sparkplug.
      
      Bug: chromium:1308178
      Change-Id: Ia5e81b376bff2aaa19e9c6007242629ab8b0d4a8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79580}
      eec3f923
  7. 17 Mar, 2022 1 commit
  8. 16 Mar, 2022 2 commits
  9. 14 Mar, 2022 1 commit
  10. 07 Mar, 2022 1 commit
  11. 01 Mar, 2022 1 commit
  12. 25 Feb, 2022 1 commit
  13. 24 Feb, 2022 2 commits
  14. 22 Feb, 2022 1 commit
    • Camillo Bruni's avatar
      [web-snapshots] Add runtime function for WebSnapshot creation Part I · a7a996ab
      Camillo Bruni authored
      This CL prepares WebSnapshot for skipping and re-injecting external
      references in the web snapshot. External references are encoded as
      separate object type and allows us to create partial snapshots at
      runtime and reconnect a deserialised snapshot to an existing
      object graph.
      
      Part II will also collect all objects which cannot be serialized by the
      web-snapshot serializer.
      
      Usage:
        snapshot = %WebSnapshotSerialize(root, skip_externals);
        object = %eWebSnapshotDeserializ(snapshot, replaced_externals);
      
      Drive-by-changes:
      - Reduce JSObject Map size in serializer (we ended up with 4 embedder
        fields)
      - Avoid adding non-HeapObject to the discovery_queue_
      - Split off ReadXXX handlers into separate functions
      
      Bug: v8:11525
      Change-Id: Ia6a9914259614c6c288667621b38daa0202d4d72
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3461936Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79211}
      a7a996ab
  15. 18 Feb, 2022 1 commit
  16. 16 Feb, 2022 1 commit
  17. 07 Feb, 2022 1 commit
    • Dominik Inführ's avatar
      [heap, objects] Check object layout changes happen on main thread · da62220f
      Dominik Inführ authored
      Verification code in HeapObject::set_map() is supposed to run on the
      main thread since object layout change is only supported on the main
      thread. There are some users of set_map() on background threads though,
      which resulted in crashes. Since those users all perform a safe map
      transition, we introduce a separate method for this purpose:
      HeapObject::set_map_safe_transition(). This method behaves just like
      set_map() but verifies that this is a safe map transition and not an
      object layout change and therefore can be used on background threads
      as well.
      
      This CL also adds a DCHECK to HeapObject::set_map() to ensure we run
      this method only on the main thread.
      
      Bug: chromium:1293484
      Change-Id: I25de6fda08de21b8b7a3645cf0ea5b1334e8a2f6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439905Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78978}
      da62220f
  18. 28 Jan, 2022 3 commits
  19. 27 Jan, 2022 1 commit
  20. 26 Jan, 2022 1 commit
    • Shu-yu Guo's avatar
      Reland^2 "[string] Support shared strings in Value{Serializer,Deserializer}" · fc23bc1d
      Shu-yu Guo authored
      This is a reland of 5320fe8d
      
      Changes since revert:
      - Remove stale DCHECK in deserializer
      
      Original change's description:
      > Reland "[string] Support shared strings in Value{Serializer,Deserializer}"
      >
      > This is a reland of 3cb4039c
      >
      > Changes since revert:
      > - Fix FLAG_stress_scavenge interaction with shared Isolate
      > - Use the shared Isolate's global handles to keep shared values
      >   alive in transit during a postMessage
      >
      > Original change's description:
      > > [string] Support shared strings in Value{Serializer,Deserializer}
      > >
      > > When FLAG_shared_string_table is true, postMessaging strings will share
      > > instead of copy.
      > >
      > > Note that not all operations on shared strings are supported, and shared
      > > strings may be slower than non-shared strings for some operations.
      
      Bug: v8:12007
      Change-Id: I70782978ed05558615eca03bafc4c12eba3644ca
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417189Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78791}
      fc23bc1d
  21. 25 Jan, 2022 1 commit
  22. 19 Jan, 2022 1 commit
  23. 14 Jan, 2022 1 commit
  24. 13 Jan, 2022 2 commits
  25. 12 Jan, 2022 1 commit
  26. 10 Jan, 2022 1 commit
  27. 16 Dec, 2021 1 commit
  28. 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
  29. 14 Dec, 2021 1 commit
  30. 08 Dec, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move Job pointer to SFI · 3b9091c8
      Leszek Swirski authored
      Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
      the sets and hashmaps, and instead:
      
        1. Turning the pending job set into a queue, and
        2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
           the LazyCompilerDispatcher::Job, instead of maintaining an
           IdentityMap from one to the other.
      
      To avoid bloating all UncompiledData, this adds two new UncompiledData
      subclasses, making it four subclasses total, for with/without Preparse
      data and with/without a Job pointer. "should_parallel_compile"
      FunctionLiterals get allocated an UncompiledData with a job pointer by
      default, otherwise enqueueing a SFI without a job pointer triggers a
      reallocation of the UncompiledData to add a job pointer.
      
      Since there is no longer a set of all Jobs (aside from one for
      debug-only), we need to be careful to manually clear the Job pointer
      from the UncompiledData whenever we finish a Job (whether successfully
      or by aborting) and we have to make sure that we implicitly can reach
      all Jobs via the pending/finalizable lists, or the set of currently
      running jobs.
      
      Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78302}
      3b9091c8
    • Marja Hölttä's avatar
      [web snapshots] De-handlify object ID lookup · 77b09f96
      Marja Hölttä authored
      Bug: v8:11525
      Change-Id: Ida18808fd299f0f5754a2693b1e6dbc93b263d77
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320424Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78284}
      77b09f96
  31. 06 Dec, 2021 1 commit