Skip to content

V
V8
Switch branch/tag
  1. 07 Feb, 2020 1 commit
  3. 05 Feb, 2020 1 commit
  5. 04 Feb, 2020 3 commits
  7. 03 Feb, 2020 2 commits
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      Sigurd Schneider authored 
      This CL implements functionality to allow an embedder to mark a
debug scope as terminate-on-resume. This results in a termination
exception when that debug scope is left and execution is resumed.
Execution of JavaScript remains possible after a debug scope is
marked as terminate-on-resume (but before execution of the paused
code resumes).
This is used by blink to correctly prevent resuming JavaScript
execution upon reload while being paused at a breakpoint.

This is important for handling reloads while paused at a breakpoint
in blink. The resume command terminates blink's nested message loop
that is used while to keep the frame responsive while the debugger
is paused. But if a reload is triggered while execution is paused
on a breakpoint, but before execution is actually resumed from the
 breakpoint (that means before returning into the V8 JavaScript
frames that are paused on the stack below the C++ frames that belong
to the nested message loop), we re-enter V8 to do tear-down actions
of the old frame. In this case Runtime.terminateExecution() cannot be
used before Debugger.resume(), because the tear-down actions that
re-enter V8 would trigger the termination exception and crash the
browser (because the browser expected the tear-down to succeed).

Hence we introduce this flag on V8 that says: It is OK if someone
re-enters V8 (to execute JS), but upon resuming from the breakpoint
(i.e. returning to the paused frames that are on the stack below),
generate a termination exception.

We deliberated adding a corresponding logic on the blink side (instead
of V8) but we think this is the simplest solution.

More details in the design doc:

https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk

Bug: chromium:1004038, chromium:1014415

Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
    • Jakob Kummerow's avatar
      [ptr-compr] Bump max string length to ~2**29 · ea56bf55
      Jakob Kummerow authored 
      Without pointer compression, the max string length on 64-bit platforms
used to be 2**30 (minus header). With pointer-compression, this was
accidentally lowered to 2**28 (which is the historical limit for 32-bit
platforms). This CL bumps the limit on 64-bit platforms to 2**29, which
is the maximum we can support given that any heap object's size in bytes
must fit into a Smi (which are now 31-bit on all 64-bit platforms, with
or without pointer compression).

Change-Id: I263544317d9e6137f6b6a044784a21f41a2761b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030916Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66083}
      ea56bf55
  9. 31 Jan, 2020 1 commit
    • Peter Marshall's avatar
      [tools] Add a VMState for Atomics.wait · e8ba5699
      Peter Marshall authored 
      We will use this state in devtools via the inspector to indicate
whether a thread is currently stuck polling in atomics.wait.

VMState already distinguishes the important states we care about which
are idle vs. running JS. We also want to know the state for
atomics.wait(), which is commonly used in WebWorkers to poll the main
page for work to do.

This CL just adds and maintains the state and adds assertions in
atomics tests. Another CL will emit inspector notifications when the
VMState changes in a way that the inspector cares about.

Re-flow comments as a drive-by cleanup.

Bug: chromium:1025490
Change-Id: I961051bfb846aa20454a56214310370ea8e47d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033168
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66071}
      e8ba5699
  11. 30 Jan, 2020 2 commits
  13. 24 Jan, 2020 2 commits
  15. 23 Jan, 2020 1 commit
  17. 22 Jan, 2020 6 commits
  19. 20 Jan, 2020 1 commit
    • Sigurd Schneider's avatar
      [coverage] Add event for coverage reporting · ee8602d3
      Sigurd Schneider authored 
      This CL adds a new event that enables the back-end to send coverage
updates on its own initiative. This event can be triggered via the C++
method `triggerPreciseCoverageDeltaUpdate` on the agent in a way that
causes coverage data to be immediatelly collected.

This is useful in the back-end to collect coverage at a certain point
in time, i.e. when a lifecycle event such as first contentful paint
occurs.

The previous interface could not support this, because it could not
reasonably be triggered from C++, and if triggered through the protocol,
dispatching messages added delay that invalidated the data (i.e. data
might have been taken too late to be accurate).

TBR=yangguo@chromium.org

Change-Id: I0f7201412a8d64866e6e314e5bc850354c13a9da
Bug: chromium:1022031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992437
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65864}
      ee8602d3
  21. 19 Jan, 2020 1 commit
    • Ulan Degenbaev's avatar
      [api] New v8::Isolate::MeasureMemory API with per-context sizes · 80242048
      Ulan Degenbaev authored 
      This adds a new API function that can be customized by the embedder
by providing a delegate that defines contexts to be measured and
reports the results to JS.

A memory measurement request is carried out as follows:

1) MeasureMemory(delegate) invocation enqueues a new request in
   MemoryMeasurement::received_ and schedules a delayed GC task.

2) At the start of the next GC (that is triggered either by the
   GC schedule or by the delayed task) each request in received_
   moves to processing_. Per-context marking worklists are created
   for each native context that was selected by the delegates
   (using the ShouldMeasure predicate).

3) At the end of the GC the sizes of the native contexts are
   recorded for each request in processing_. The requests move
   to the done_ list and result reporting task is scheduled.

4) When the result reporting task runs it invokes the
   MeasurementComplete function of each delegate in done_.


Bug: chromium:973627

Change-Id: I0254cae693c5b8fab7c85a9eca0a3a128210b6c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981493
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65856}
      80242048
  23. 16 Jan, 2020 2 commits
  25. 14 Jan, 2020 2 commits
  27. 13 Jan, 2020 2 commits
  29. 10 Jan, 2020 2 commits
  31. 08 Jan, 2020 1 commit
  33. 07 Jan, 2020 1 commit
  35. 19 Dec, 2019 1 commit
  37. 18 Dec, 2019 1 commit
  39. 17 Dec, 2019 1 commit
    • Peter Marshall's avatar
      [unwinder] Add a vector-based code page mechanism for arm32 · 285e4d69
      Peter Marshall authored 
      Add an API on Isolate that returns a sorted vector of code pages allocated
within V8. The implementation is designed to be signal-safe, so that the
user (the UMA sampling profiler) can access this information from a signal
handler, where allocation and taking locks is prohibited.

This CL adds the machinery for maintaining the list of allocated code
pages. Further CLs will modify the Unwinder API itself to accept the code
pages provided by this API.

The unwinder API currently uses the reserved virtual-memory range called
the CodeRange to identify where all V8 code objects live, but this doesn't
exist on arm32 or any 32-bit platform, so this approach adds a way to
expose the location of all valid V8 code objects in a signal-safe way for
use by the UMA sampling profiler.

On 64-bit, this API always gives the code_range and embedded_code_range, and
does not maintain a vector of code pages. This is so that we have a unified
API on 32 and 64-bit that can be used in exactly the same way by embedders.

Design doc:
https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0

Bug: v8:8116
Change-Id: I732509a45121fc54853182481c24d1083275afce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564068
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65469}
      285e4d69
  41. 13 Dec, 2019 3 commits
  43. 10 Dec, 2019 2 commits
  45. 09 Dec, 2019 1 commit