Skip to content

V
V8
Switch branch/tag
  1. 22 Dec, 2020 1 commit
  3. 10 Dec, 2020 1 commit
  5. 08 Dec, 2020 4 commits
  7. 26 Nov, 2020 1 commit
  9. 24 Nov, 2020 1 commit
  11. 20 Nov, 2020 2 commits
  13. 19 Nov, 2020 1 commit
  15. 18 Nov, 2020 1 commit
  17. 13 Nov, 2020 1 commit
  19. 11 Nov, 2020 2 commits
  21. 29 Oct, 2020 2 commits
  23. 28 Oct, 2020 4 commits
  25. 27 Oct, 2020 5 commits
    • Nicolas Dubus's avatar
      [cpu-profiler] Return CpuStartProfilingStatus when starting profiling · a5490e39
      Nicolas Dubus authored 
       - Created status enum with statuses kStarted, kAlreadyStarted and
kErrorTooManyProfilers, returning when StartProfiling is invoked
 - Tests spin up one profiler, check kStarted returned; spin up
another with same name, check kAlreadyStarted returned; Spin up 99
more profilers (100 total), check each returning kStarted, and
one more, expecting 101st to return kErrorTooManyProfilers

R=acomminos@fb.com, petermarshall@chromium.org, ulan@chromium.org

Change-Id: I64e2e6396775f90f9f49f75331a075a47efa7fca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486240Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70808}
      a5490e39
    • Mythri Alle's avatar
      Revert "[turboprop] Add a slot for optimization marker in feedback vector" · a78c65f9
      Mythri Alle authored 
      This reverts commit d7ece57e.

Reason for revert: failures on NumFuzz 
https://ci.chromium.org/p/v8/builders/ci/V8%20NumFuzz%20-%20debug/11818?

Original change's description:
> [turboprop] Add a slot for optimization marker in feedback vector
>
> Optimization marker and the optimized code used to share the same slot
> in the feedback vector as they were mutually exclusive. With turboprop
> we would want to mark the function for tier up to Turbofan while holding
> the optimized code for Turboprop. So this cl uses the existing padding
> field to hold the optimization marker instead.
>
> As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
> and fixes a minor bug in Runtime_GetOptimizationStatus.
>
> Bug: v8:9684
> Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70789}

TBR=rmcilroy@chromium.org,mythria@chromium.org,jgruber@chromium.org

Change-Id: Ia9894fef713a522b9c3d349bef4abcde3e1e1832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502870Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70803}
      a78c65f9
    • Peter Marshall's avatar
      [cpu-profiler] Clear the CodeMap after the last profile to stop leak · 73a94290
      Peter Marshall authored 
      We kept the CodeMap filled with entries between profiles, even in
kLazyLogging mode which will re-fill the CodeMap when profiling starts
again. See the bug for more details.

This fix manually clears the CodeMap after the last profile is deleted.
We already call DisableLogging() when the last profile is stopped. At
this point we still need the CodeMap alive because the profile object
we expose via the API is backed by the CodeEntry objects in the CodeMap.
Once the last profile is deleted though, we can empty the CodeMap.

There is still another bug, which is that we never delete CodeEntry
objects for deleted code, as there are no CodeDeleteEvents from the GC.
We will work on that separately, but this fix should stop those leaks
accumulating between profiles as we wipe the CodeMap entirely between
profiles (at least for kLazyLogging mode). kEagerLogging mode still has
this problem and will only be fixed by introducing CodeDelete events or
similar.

Bug: v8:11051
Change-Id: Iab9570747d17c657e6e318d434f935af8047d05f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491033
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70792}
      73a94290
    • Mythri A's avatar
      [turboprop] Add a slot for optimization marker in feedback vector · d7ece57e
      Mythri A authored 
      Optimization marker and the optimized code used to share the same slot
in the feedback vector as they were mutually exclusive. With turboprop
we would want to mark the function for tier up to Turbofan while holding
the optimized code for Turboprop. So this cl uses the existing padding
field to hold the optimization marker instead.

As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
and fixes a minor bug in Runtime_GetOptimizationStatus.

Bug: v8:9684
Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70789}
      d7ece57e
    • Charles Kerr's avatar
      perf: make GetPositionInfoSlow() faster · 2e2dc986
      Charles Kerr authored 
      Halve the number of lookups in ExtractLocationForJSFunction() by calling
GetPositionInfo() directly instead of making separate calls for column
and line number.

Improve the efficiency of position lookups in slow mode. The current
code does a linear walk through the source by calling String::Get() for
each character. This PR also does a linear walk, but avoids the overhead
of multiple Get() calls by pulling the String's flat content into a
local vector and walking through that.

Downstream Electron discussion of this can be found at
https://github.com/electron/electron/issues/24509

Apologies in advance if I've missed anything; this is my first V8 CL...

Change-Id: I22b034dc1bfe967164d2f8515a9a0c1d7f043c83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2496065
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70783}
      2e2dc986
  27. 26 Oct, 2020 1 commit
  29. 20 Oct, 2020 1 commit
  31. 16 Oct, 2020 3 commits
    • Michael Lippautz's avatar
      Reland "cppgc-js: Add snapshot for C++ objects" · 063d56e7
      Michael Lippautz authored 
      This reverts commit fba14bde.

Reland fixes:
- const vector<const string> -> const vector<string>

Original message:
The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.

C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
   configuration requires Oilpan to hide such names. Hidden objects have
   their name set to NameProvider::kHiddenName.

The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
  ...  -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.

Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
   reach non-hidden objects as visible. Details:
   - Iterate over all objects.
   - If object is non-hidden mark it as visible and also mark parent
     as visible if needed.
   - If object is hidden, traverse children as DFS to find non-hidden
     objects. Post-order process the objects and mark those objects as
     visible that have child nodes that are visible themselves.
   - Maintain an epoch counter (StateStorage::state_count_) to allow
     deferring the visibility decision to other objects in the same
     SCC. This is similar to the "lowlink" value in Tarjan's algorithm
     for SCC.
   - After the first pass it is guaranteed that all deferred
     visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
   - Upon first checking the visibility state of an object, all deferred
     visibility states are resolved.

For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.

Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
   wrappers.
2. Adding detachedness information.

Bug: chromium:1056170
Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70577}
      063d56e7
    • Maya Lekova's avatar
      Revert "cppgc-js: Add snapshot for C++ objects" · fba14bde
      Maya Lekova authored 
      This reverts commit 02849fd9.

Reason for revert: Breaks Win64 MSVC bot and closes the tree - https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/15416

Original change's description:
> cppgc-js: Add snapshot for C++ objects
>
> The following implements a snapshotting algorithm for C++ objects that
> also filters strongly-connected components (SCCs) of only "hidden"
> objects that are not (transitively) referencing any non-hidden
> objects.
>
> C++ objects come in two versions.
> a. Named objects that have been assigned a name through NameProvider.
> b. Unnamed objects, that are potentially hidden if the build
>    configuration requires Oilpan to hide such names. Hidden objects have
>    their name set to NameProvider::kHiddenName.
>
> The main challenge for the algorithm is to avoid blowing up the final
> object graph with hidden nodes that do not carry information. For that
> reason, the algorithm filters SCCs of only hidden objects, e.g.:
>   ...  -> (object) -> (object) -> (hidden) -> (hidden)
> In this case the (hidden) objects are filtered from the graph. The
> trickiest part is maintaining visibility state for objects referencing
> other objects that are currently being processed.
>
> Main algorithm idea (two passes):
> 1. First pass marks all non-hidden objects and those that transitively
>    reach non-hidden objects as visible. Details:
>    - Iterate over all objects.
>    - If object is non-hidden mark it as visible and also mark parent
>      as visible if needed.
>    - If object is hidden, traverse children as DFS to find non-hidden
>      objects. Post-order process the objects and mark those objects as
>      visible that have child nodes that are visible themselves.
>    - Maintain an epoch counter (StateStorage::state_count_) to allow
>      deferring the visibility decision to other objects in the same
>      SCC. This is similar to the "lowlink" value in Tarjan's algorithm
>      for SCC.
>    - After the first pass it is guaranteed that all deferred
>      visibility decisions can be resolved.
> 2. Second pass adds nodes and edges for all visible objects.
>    - Upon first checking the visibility state of an object, all deferred
>      visibility states are resolved.
>
> For practical reasons, the recursion is transformed into an iteration.
> We do not use plain Tarjan's algorithm to avoid another pass over
> all nodes to create SCCs.
>
> Follow ups:
> 1. Adding wrapper nodes for cpp objects that are wrappables for V8
>    wrappers.
> 2. Adding detachedness information.
>
> Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
> Bug: chromium:1056170
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70567}

TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org

Change-Id: I64a2cf2259bdaed81f6e0f92bdcc7a1f0df4d197
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479471Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70571}
      fba14bde
    • Michael Lippautz's avatar
      cppgc-js: Add snapshot for C++ objects · 02849fd9
      Michael Lippautz authored 
      The following implements a snapshotting algorithm for C++ objects that
also filters strongly-connected components (SCCs) of only "hidden"
objects that are not (transitively) referencing any non-hidden
objects.

C++ objects come in two versions.
a. Named objects that have been assigned a name through NameProvider.
b. Unnamed objects, that are potentially hidden if the build
   configuration requires Oilpan to hide such names. Hidden objects have
   their name set to NameProvider::kHiddenName.

The main challenge for the algorithm is to avoid blowing up the final
object graph with hidden nodes that do not carry information. For that
reason, the algorithm filters SCCs of only hidden objects, e.g.:
  ...  -> (object) -> (object) -> (hidden) -> (hidden)
In this case the (hidden) objects are filtered from the graph. The
trickiest part is maintaining visibility state for objects referencing
other objects that are currently being processed.

Main algorithm idea (two passes):
1. First pass marks all non-hidden objects and those that transitively
   reach non-hidden objects as visible. Details:
   - Iterate over all objects.
   - If object is non-hidden mark it as visible and also mark parent
     as visible if needed.
   - If object is hidden, traverse children as DFS to find non-hidden
     objects. Post-order process the objects and mark those objects as
     visible that have child nodes that are visible themselves.
   - Maintain an epoch counter (StateStorage::state_count_) to allow
     deferring the visibility decision to other objects in the same
     SCC. This is similar to the "lowlink" value in Tarjan's algorithm
     for SCC.
   - After the first pass it is guaranteed that all deferred
     visibility decisions can be resolved.
2. Second pass adds nodes and edges for all visible objects.
   - Upon first checking the visibility state of an object, all deferred
     visibility states are resolved.

For practical reasons, the recursion is transformed into an iteration.
We do not use plain Tarjan's algorithm to avoid another pass over
all nodes to create SCCs.

Follow ups:
1. Adding wrapper nodes for cpp objects that are wrappables for V8
   wrappers.
2. Adding detachedness information.

Change-Id: I6e127d2c6d65e77defe08e39295a2594f463b962
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467854
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70567}
      02849fd9
  33. 12 Oct, 2020 1 commit
    • Anna Henningsen's avatar
      [heap-profiler] Fix crash when a snapshot deleted while taking one · 3176bfd4
      Anna Henningsen authored 
      Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.

Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.

Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.

This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.

Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464823Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
      3176bfd4
  35. 08 Oct, 2020 1 commit
  37. 07 Oct, 2020 1 commit
  39. 05 Oct, 2020 1 commit
  41. 03 Oct, 2020 1 commit
  43. 01 Oct, 2020 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Refactor ProfileGenerator · 82efa4bd
      Peter Marshall authored 
      Rename it to Symbolizer because it does exactly that.

Change the SymbolizeTickSample method to return the symbolized state
rather than pass it on to the ProfilesCollection. This makes it easier
to test as now it only relies on the CodeMap provided to it.

Make EntryForVMState a free-floating function as it doesn't rely on
state and then we can avoid importing the StateTag definition in the
header.

Remove the UNREACHABLE from EntryForVMState as the compiler got smarter
and doesn't need it anymore.

Pass the CpuProfilesCollection to SamplingEventsProcessor instead,
as it is now responsible for putting the symbolized samples into the
collection to be sorted into the appropriate profiles.

Change-Id: I104290eff22b7d94a1bd34ba904036badccf4e13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440522
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70248}
      82efa4bd
  45. 23 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [profiler] Include the generic js-to-wasm builtin in profiles · f20230af
      Clemens Backes authored 
      This CL fixes two things:
1) It properly creates code entries for the generic js-to-wasm builtin
(others are left out because we don't want to include all builtins in
profiles).
2) It includes js-to-wasm frames in profiles. The generic js-to-wasm
builtin will map to that frame type in the future (see referenced
bug). js-to-wasm frames are currently included because they are wrongly
mapped to OPTIMIZED frames by the SafeStackTraceIterator.

R=petermarshall@chromium.org
CC=ahaas@chromium.org, evih@google.com

Bug: v8:10701
Change-Id: I26e3fa6901890e041feab7c001069e67a616c986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416495Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70095}
      f20230af
  47. 18 Sep, 2020 1 commit
  49. 16 Sep, 2020 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · 76217f57
      Alex Kodat authored 
      While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be using isolate->js_entry_sp
to determine the stack to walk but isolate->js_entry_sp is the stack
pointer for the thread that currently has the Isolate lock so, if the
sampled thread does not have the lock, the sampler woud be iterating
over the wrong stack, one that might actually be actively changing on
another thread. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iba6cabcd3e11a19c261c004103e37e806934dc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411343Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69952}
      76217f57