Skip to content

V
V8
Switch branch/tag
  1. 12 Feb, 2021 3 commits
  3. 11 Feb, 2021 1 commit
  5. 10 Feb, 2021 1 commit
  7. 09 Feb, 2021 1 commit
  9. 05 Feb, 2021 1 commit
  11. 28 Jan, 2021 1 commit
  13. 26 Jan, 2021 2 commits
  15. 22 Jan, 2021 1 commit
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Use base::LeakyObject for static CodeEntry objects" · 93f8a867
      Peter Marshall authored 
      This is a reland of c594a20e

Moved the getters to the .cc file to avoid link problems as they
are not performance critical anyway.

Moved ProfileNode::source_type to cc as it uses the _entry() functions
which are no longer inline.

Original change's description:
> [cpu-profiler] Use base::LeakyObject for static CodeEntry objects
>
> This is preferred over the older LazyInstance based stuff, and has
> a lot less boilerplate and is easier to follow.
>
> Bug: v8:8600
> Change-Id: I7c5c5ae04c064b0fc598dc01f1ed5442dc21a17b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640475
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72224}

Bug: v8:8600
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Change-Id: I0ad9118e6d3bd087707609714b20aee1cbc4f459
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642252
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72254}
      93f8a867
  17. 21 Jan, 2021 2 commits
  19. 20 Jan, 2021 2 commits
    • Peter Marshall's avatar
      [cpu-profiler] Add a codeType to the tracing output · 14ad529b
      Peter Marshall authored 
      DevTools can't unambiguously determine whether code is JS or wasm.
This CL adds a string to the tracing output that will be 'JS', 'wasm' or
'other'.

Bug: chromium:1168052
Change-Id: Iaacb5ea9a83327e22d60bf6114f607e6fa5532ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637859
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72193}
      14ad529b
    • Seth Brenith's avatar
      [torque] Begin porting ScopeInfo to Torque · ecaac329
      Seth Brenith authored 
      This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.

Torque compiler changes:

- Fix an issue where the parser created constexpr types for classes
  based on the class name rather than the `generates` clause. This meant
  that generated accessors referred to the imaginary type HashTable
  rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
  implement Torque macros. Maybe we'll need it eventually, but we don't
  right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
  Instead, emit a member function `SomeFieldOffset()` which fetches the
  slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
  complex length expressions. It fetches the slice for the last field
  and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
  the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.

With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:

1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
   and use them
3. Get rid of the FixedArray-style get and set accessors; use
   TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
   unnecessary `length` field

After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.

Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
      ecaac329
  21. 18 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [heap-profiler][torque] Report types of all internal objects · e3f8b5db
      Seth Brenith authored 
      Heap-profiler changes:

Currently, a whole lot of types are all reported as just "system" in
heap snapshots. With this change, we can use Torque-generated macro
lists to easily report type names such as "system / BytecodeArray".
Those objects still show up in a single category named "(system)" in the
dev tools UI, so they don't clutter the output. For V8 developers or
anybody who is interested in an extra-detailed view, this change also
includes a runtime flag that instructs V8 to upgrade nodes of type
kHidden to type kNative. After a snapshot is collected with this flag
enabled, the dev tools UI then shows each internal object type
separately.

Torque changes:

Currently, Torque emits several macro lists containing pairs of
(ClassName, CLASS_NAME_TYPE) which can be used to associate instance
types with Torque class names. However, some Torque classes are not
included in any of these three lists. In cases like the heap profiler,
it would be nice to easily generate a complete list including every
instance type, so this CL includes two changes:

- Include classes in TORQUE_INSTANCE_CHECKERS_MULTIPLE_FULLY_DEFINED
  even if they're not marked `extern`. I'm not sure what exactly we
  were hoping to accomplish in filtering by extern-ness, but it's
  simpler not to and slightly reduces clutter in a couple of files that
  use that macro list.
- Add a fourth macro list for the previously-ignored category: classes
  which have their own instance type (are not `abstract`), and have
  subtypes, but do not have their fields defined in Torque. This list
  contains just a single item (HashTable), but I like the consistency of
  generating the full set of lists.

Change-Id: Ib24953e12ed13ce353206bbec23a52d8f684dfcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610172
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72138}
      e3f8b5db
  23. 15 Jan, 2021 1 commit
    • Alex Kodat's avatar
      [cpu-profiler] Don't sample wrong thread's stack in profiler · bf9e8d2c
      Alex Kodat authored 
      76217f57 fixed the profiler so it would only sample a thread if
it had the Isolate lock. Unfortunately, this fix missed a timing
window where a thread might have the Isolate lock but might not
have restored the thread-specific data such as thread_local_top_
for the locked thread yet, so the sampler might end up using data
from a different thread.

This doesn't cause any seg faults or the like because the thread
we *meant* to sample has the Isolate lock so the thread we're
accidentally sampling can't mess with any Isolate data but we can
still get incorrect sample data which can be especially obvious if
the accidentally sampled thread is inside code that would never
run on the thread we meant to sample.

Fortunately, we can tell when all thread-specific data has been
restored to the Isolate because thread_state_ in the
PerIsolateThreadData for a thread is set to a non-null value
until everything has been restored, at which point it gets set
to null. So the fix adds a check after the test for the Isolate
lock to check if thread_state_ is null for the thread we mean to
sample. If so, we know all the data in the Isolate is good to go
for sampling.

Bug: v8:11316
Change-Id: I02d6361d8cbd6ec809ad8fb7ef07f5e9c94c7d1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628133Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72112}
      bf9e8d2c
  25. 11 Jan, 2021 1 commit
  27. 07 Jan, 2021 1 commit
  29. 22 Dec, 2020 1 commit
  31. 10 Dec, 2020 1 commit
  33. 08 Dec, 2020 4 commits
  35. 26 Nov, 2020 1 commit
  37. 24 Nov, 2020 1 commit
  39. 20 Nov, 2020 2 commits
  41. 19 Nov, 2020 1 commit
  43. 18 Nov, 2020 1 commit
  45. 13 Nov, 2020 1 commit
  47. 11 Nov, 2020 2 commits
  49. 29 Oct, 2020 2 commits
  51. 28 Oct, 2020 4 commits