1. 29 Aug, 2022 3 commits
  2. 26 Aug, 2022 1 commit
  3. 24 Aug, 2022 1 commit
  4. 22 Aug, 2022 1 commit
    • ishell@chromium.org's avatar
      [runtime] Merge redirected and non-redirected callback fields · 134ca75c
      ishell@chromium.org authored
      Namely:
       - AccessorInfo::getter and AccessorInfo::js_getter,
       - CallHandlerInfo::callback and CallHandlerInfo::js_callback.
      
      The redirected/non-redirected callback distinction is required only
      for simulated builds but we wasted memory also for all native builds.
      
      Now we store these fields in "redirected" form which allows us to call
      them directly from builtins or generated code. In case it's necessary
      to call a callback from C++ code the C function address is read from
      the redirection. This additional indirection makes the callback calls
      from C++ code in simulated builds slower but saves memory for native
      builds.
      
      This CL should recover a part of memory regression caused by inlining
      Foreign fields into AccessorInfo and CallHandlerInfo.
      
      Bug: v8:12949, chromium:1336105, chromium:1335930
      Change-Id: I38470ed21ee23b281247c11a9531542c7e4acca1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835686Reviewed-by: 's avatarJakob Linke <jgruber@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82631}
      134ca75c
  5. 19 Aug, 2022 2 commits
  6. 16 Aug, 2022 1 commit
    • Camillo's avatar
      [api] Advance API deprecation · 65034fdf
      Camillo authored
      Remove the following deprecated functions:
      include/v8-inspector.h:364 v10.3  Use version with client_is_trusted argument
      include/v8-locker.h:130    v10.3  This method will be removed.
      include/v8-message.h:90    v10.3  Use GetHostDefinedOptions
      include/v8-script.h:51     v10.0  Use HostDefinedOptions
      include/v8-script.h:671    v10.0  Use CompileFunction
      
      Output generated by tools/release/list_deprecated.py.
      
      Remove CompileFunctionInContext for chrome and only implement it if
      V8_SCRIPTORMODULE_LEGACY_LIFETIME is defined.
      
      Change-Id: I33dd3665220f484e277e66f340e17ed2c3b49916
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3702449Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Auto-Submit: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82476}
      65034fdf
  7. 11 Aug, 2022 2 commits
  8. 10 Aug, 2022 1 commit
    • Michael Lippautz's avatar
      Reland "[handles] Remove precise on-stack representation of global handles" · 65d43890
      Michael Lippautz authored
      This is a reland of commit 6953b555
      
      The reland fixes tests that retrieved the stack start from a
      non-inlined frame's fp. This does not work in certain configurations
      as the resulting marker is too low to consider the first local
      variables in subsequent calls.
      
      The fix uses an inline frame address for the tests to get an upper
      bound of stack addresses to consider.
      
      Original change's description:
      > [handles] Remove precise on-stack representation of global handles
      >
      > Since https://crrev.com/c/3806439 on-stack traced handles are marked
      > conservatively when being used in combination with CppHeap.
      >
      > This change removes the precise on-stack representation of the
      > internal traced nodes as they nodes would anyways be marked
      > conservatively. The effects are:
      > - cheaper representation (just a single node space);
      > - uniform handling: no checks to distinguish on-stack vs on-heap;
      > - no brittleness around cleaning on-stack handles when the event loop
      >  is empty;
      >
      > Change-Id: Id859623bfed77a66bdd064ea8065536264515eae
      > Bug: v8:13141
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3812039
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82306}
      
      Bug: v8:13141
      Change-Id: I53ece36220e99d02be6df18f83c18450e5d5037b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820585Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82342}
      65d43890
  9. 09 Aug, 2022 3 commits
  10. 08 Aug, 2022 1 commit
  11. 05 Aug, 2022 1 commit
  12. 02 Aug, 2022 1 commit
    • Michael Lippautz's avatar
      Revert "[heap, api] Check assumptions for embedder fields on set" · bcd0fa55
      Michael Lippautz authored
      This reverts commit 61193620.
      
      Reason for revert: Blocking roll: https://chromium-review.googlesource.com/c/chromium/src/+/3802992/
      
      Original change's description:
      > [heap, api] Check assumptions for embedder fields on set
      >
      > Previously, we would set embedder fields and do type checks (on
      > embedder fields) in the GC. This does not work nicely as embedder
      > fields contain system pointers whereas we can only operate with
      > tag-aligned reads/writes. The end result of assembling pointers was
      > somtimes broken for concurrent marking.
      >
      > In this CL we reverse the mode and check assumptions when writing the
      > fields. From Blink we generally only write once and use the fields in
      > the GC and via reads multiple times.
      >
      > We assume, that when running with CppHeap, any pointer on an instance
      > field that points into CppHeap, also has the type field set with the
      > appropriate tracing information. In debug builds we also verify that
      > the embedder field indeed points to the start of an Oilpan object.
      >
      > Bug: chromium:1337690
      > Change-Id: I9f9a8e691cdcf666861a455dcf8f65f2fe80b034
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788206
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#82120}
      
      Bug: chromium:1337690
      Change-Id: Iaece8f51883c7d001fb18ef48faaf271c48b8f11
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3804245
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#82127}
      bcd0fa55
  13. 01 Aug, 2022 3 commits
  14. 28 Jul, 2022 1 commit
  15. 22 Jul, 2022 1 commit
  16. 15 Jul, 2022 2 commits
  17. 12 Jul, 2022 1 commit
    • Jose Dapena Paz's avatar
      [profiler] Emit ETW events only on a trace session. · 0e7d5763
      Jose Dapena Paz authored
      If a tracing session starts after a script load has happened, then it is
      not emitted, so the source information is not visible in ETW. This is
      because we keep track of the loads already emitted, and we try to launch
      traces even when recording is not happening.
      
      To prevent this problem, this CS keeps track of when recording is
      happening. So, when it starts, it will emit all the already generated
      code immediately. This will add some overhead on tracing session start
      if system instrumentation is enabled, but this is better than not
      having instrumentation for previous symbols.
      
      There is still one problem: for each active isolate, it calls for
      replaying the event recording in an asynchronous task. So, for any
      JS task that is already running when tracing start, symbols will not
      be available. This makes this change less useful as, for a batch task
      or any long JS code that is already running when tracing start, we
      will not get symbols yet. Only after the foreground task runner runs
      the task to emit the ETW events we will get the symbols resolved in
      the trace.
      
      An specific approach was required for d8 interactive shell. As, when
      showing prompt, it is not processing the task runner queue, and it
      is only processed when the next script is launched, it first checks
      if it needs to generate ETW symbols information before running the
      script.
      
      Bug: v8:12932
      Change-Id: I8b056c69cee0350f921a01c87beb9f2d51e10583
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705541Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: José Dapena Paz <jdapena@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#81673}
      0e7d5763
  18. 11 Jul, 2022 3 commits
    • Maksim Sadym's avatar
      Fix Date BiDi format · 126d4779
      Maksim Sadym authored
      1. Add `toISOString` to `v8::Date`.
      2. Switch serialization to `ISOString`.
      
      Bug: v8:13043
      Change-Id: I8a852f4a4a46bb3b8e5d52ef3cdffde7a408b403
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749203
      Auto-Submit: Maksim Sadym <sadym@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81647}
      126d4779
    • Joyee Cheung's avatar
      [serializer] allow SnapshotCreator to destruct without a blob · f3cad8ce
      Joyee Cheung authored
      Previously SnapshotCreator demanded a blob to be created before
      it can be destructed in debug build, this patch removes the
      DCHECK so that the embedder can choose not to create the blob
      when e.g. the snapshot building isn't successful due to errors.
      
      Change-Id: I72939be1e0d79b257b9761f48a72e45325a1f6d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716682Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#81644}
      f3cad8ce
    • Samuel Groß's avatar
      [sandbox] Prepare ExternalPointerTable rollout · 8a59678b
      Samuel Groß authored
      This CL does the following:
      - It enables (i.e. allocates and initializes) the per-Isolate
        ExternalPointerTable when the sandbox is enabled.
      - It refactors the list of external pointer tags to mark them as
        "sandboxed" or "unsandboxed". An unsandboxed external pointer has a
        null tag.
      - It changes V8_SANDBOXED_EXTERNAL_POINTERS to now essentially just
        enable sandboxing for all available tags.
      - It modifies all low-level external pointer accessors to perform the
        ExternalPointerLookup only if the tag is non-zero and otherwise treat
        the slot as containing a raw pointer.
      
      This now allows rolling out external pointer sandboxing incrementally
      (separately for each external pointer type), which will in turn allow
      for more precise performance measurements of the impact of the sandbox.
      
      Note: when an external pointer tag is now marked as sandboxed (and
      V8_SANDBOXED_EXTERNAL_POINTERS is not enabled), the underlying slots are
      still 64-bits in size. This simplifies the implementation as we would
      otherwise need to deal with variably-sized external pointer slots. Local
      benchmarking suggests that the benefits from 32-bit external pointer
      slots are insignificant on typical benchmarks, so this should be ok.
      
      Drive-by: rename kExternalPointerSize to kExternalPointerSlotSize to
      make it more clear what it refers to (the on-heap storage size). Also
      delete CodeStubAssembler::InitializeExternalPointerField as it is not
      currently used and the implementation is fairly inefficient.
      
      Bug: v8:10391
      Change-Id: I7c38729c7e9048d737a1a8ced84749f5b1f7feab
      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/+/3736447Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81636}
      8a59678b
  19. 07 Jul, 2022 1 commit
  20. 05 Jul, 2022 3 commits
  21. 01 Jul, 2022 1 commit
  22. 28 Jun, 2022 2 commits
  23. 27 Jun, 2022 1 commit
    • Samuel Groß's avatar
      [sandbox] Turn ExternalPointerTag into a template parameter · 8ca93205
      Samuel Groß authored
      The ExternalPointerTags are assumed to be compile-time constants in most
      cases, so turning them into template parameters enforces that. As
      decisions such as whether to use the per-isolate or the shared external
      pointer table are encoded into the tag values, forcing those to be
      compile-time constants guarantees that the compiler will be able to
      inline the correct logic when accessing an external pointer.
      
      With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods
      which require the ExternalPointerTag to be a template parameter, and the
      ExternalPointerSlot class which takes the tag as an argument. The latter
      is for example used for snapshot deserialization and by the garbage
      collector (more generally, by the ObjectVisitor::VisitExternalPointer
      method), where the tag is not a compile-time constant.
      
      Finally, this CL also introduces a new ExternalPointerHandle type which
      represents the (opaque) on-heap representation of a reference to an
      entry in an ExternalPointerTable when sandboxing is enabled. Making this
      its own type makes the code a bit more readable.
      
      Bug: v8:10391
      Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb
      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/+/3720641Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      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@{#81402}
      8ca93205
  24. 21 Jun, 2022 1 commit
  25. 20 Jun, 2022 2 commits