Skip to content

V
V8
Switch branch/tag
  1. 30 Jan, 2020 1 commit
  3. 24 Jan, 2020 2 commits
  5. 23 Jan, 2020 1 commit
  7. 22 Jan, 2020 6 commits
  9. 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
  11. 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
  13. 16 Jan, 2020 2 commits
  15. 14 Jan, 2020 2 commits
  17. 13 Jan, 2020 2 commits
  19. 10 Jan, 2020 2 commits
  21. 08 Jan, 2020 1 commit
  23. 07 Jan, 2020 1 commit
  25. 19 Dec, 2019 1 commit
  27. 18 Dec, 2019 1 commit
  29. 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
  31. 13 Dec, 2019 3 commits
  33. 10 Dec, 2019 2 commits
  35. 09 Dec, 2019 1 commit
  37. 05 Dec, 2019 1 commit
  39. 04 Dec, 2019 2 commits
  41. 02 Dec, 2019 2 commits
  43. 28 Nov, 2019 1 commit
  45. 27 Nov, 2019 2 commits
  47. 18 Nov, 2019 1 commit