Skip to content

V
V8
Switch branch/tag
  1. 09 Mar, 2021 1 commit
    • pthier's avatar
      Reland "[sparkplug] Change bytecode offset mapping and introduce iterator." · 2966c896
      pthier authored 
      This is a reland of a8b61ef5

The main reason for the revert was not related to this CL and was fixed
with https://crrev.com/c/2739646
In addition debug output in d8.test.verifySourcePositions was removed
due to TSAN complaints.

Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}
>
> Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6

Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745335Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73293}
      2966c896
  3. 08 Mar, 2021 1 commit
  5. 05 Mar, 2021 3 commits
  7. 04 Mar, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[sparkplug] Change bytecode offset mapping and introduce iterator." · 6fa780ff
      Maya Lekova authored 
      This reverts commit a8b61ef5.

Reason for revert: Looks like it breaks GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/35880/overview

Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
> flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}

Bug: v8:11420
Bug: v8:11429
Change-Id: Ie71e7ce234e7b9ab9a2ec99a983e9900f35baa44
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735397
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73187}
      6fa780ff
    • pthier's avatar
      [sparkplug] Change bytecode offset mapping and introduce iterator. · a8b61ef5
      pthier authored 
      Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
create a mapping of bytecode offset <-> sparkplug pc.
These pairs were only recorded after builtin/runtime calls.
In preparation for deoptimizing to Sparkplug, we need a more precise
mapping.
With this CL, we record positions for every bytecode. Instead of storing
a pair of (bytecode offset, sparkplug pc), we store only the pc,
calculating the bytecode offset from the index in the mapping table.
For easier use an iterator to access the mapping is introduced.

Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.

Bug: v8:11420, v8:11429
Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73186}
      a8b61ef5
  9. 25 Feb, 2021 2 commits
    • Hannes Payer's avatar
      Update OWNERS in src/* · 05774c15
      Hannes Payer authored 
      Change-Id: Ib54d5abad3e67f74d1930af135778e1f201ba28f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712964
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73050}
      05774c15
    • Leszek Swirski's avatar
      [profiler] Clean up CodeEvent tags · 9a31804b
      Leszek Swirski authored 
      Clean-up and slightly unify the CodeEvent tags:

  * Remove INTERPRETED_FUNCTION_TAG. It was only used for interpreter
    trampoline copies, which are used for
    --interpreted-frames-native-stack.  However, even actual bytecode
    compilation doesn't use INTERPRETED_FUNCTION_TAG, so we can remove
    it for simplicity.

  * The tag used by the above is now the same as for the bytecode
    creation event, i.e. EVAL_TAG, SCRIPT_TAG, FUNCTION_TAG or
    LAZY_COMPILE, depending on whether this was a script, and eval, an
    eager or a lazy compile (respectively.

  * Baseline was also using INTERPRETED_FUNCTION_TAG, so now it does the
    same thing as above.

  * Existing code is now logged as FUNCTION_TAG rather than
    LAZY_COMPILE, because we lost the laziness information.

  * The SCRIPT_TAG is set based on the SharedFunctionInfo flags, not
    the compilation flags, so that eager inner functions are labelled as
    FUNCTION_TAG rather than SCRIPT_TAG.

Bug: v8:11420,v8:11429
Change-Id: I0286002674255ff4ba8f5d865df372a3e2975b16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713104Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73047}
      9a31804b
  11. 24 Feb, 2021 1 commit
  13. 23 Feb, 2021 1 commit
  15. 19 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Revert "Remove 'length' field from ScopeInfo" · 6c922e39
      Seth Brenith authored 
      This reverts commit f731e13f.

Reason for revert: perf regressions, chromium:1179757

Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
>   supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
>   ScopeInfo fields by index, and move them from scope-info-inl.h to
>   scope-info.cc. Those functions are still used pretty heavily during
>   initialization (ScopeInfo::Create, etc.), but at least we can avoid
>   presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
>   It maintains the existing behavior of filling the newly-allocated
>   object with undefined, even though that's not a valid ScopeInfo and
>   further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
>   Torque macro, because it used to rely on casting ScopeInfo to
>   FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
>   arrays. I think it makes more sense to list them under "(system)" in
>   the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}

Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
      6c922e39
  17. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Remove 'length' field from ScopeInfo · f731e13f
      Seth Brenith authored 
      ScopeInfo has a vestigial 'length' field from when it used to be a
FixedArray. This change removes that field, which saves some memory.

More specifically:

- Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
  supplied the 'length' field.
- Privatize the FixedArray-style functions that provide access to
  ScopeInfo fields by index, and move them from scope-info-inl.h to
  scope-info.cc. Those functions are still used pretty heavily during
  initialization (ScopeInfo::Create, etc.), but at least we can avoid
  presenting them to the rest of the world.
- Change FactoryBase::NewScopeInfo to allocate the updated object shape.
  It maintains the existing behavior of filling the newly-allocated
  object with undefined, even though that's not a valid ScopeInfo and
  further initialization is required.
- Move part of AccessorAssembler::ScriptContextTableLookup into a new
  Torque macro, because it used to rely on casting ScopeInfo to
  FixedArrayBase.
- In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
  arrays. I think it makes more sense to list them under "(system)" in
  the dev tools, like most other V8 internal types.

Bug: v8:8952
Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-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 avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72830}
      f731e13f
  19. 16 Feb, 2021 1 commit
  21. 12 Feb, 2021 3 commits
  23. 11 Feb, 2021 1 commit
  25. 10 Feb, 2021 1 commit
  27. 09 Feb, 2021 1 commit
  29. 05 Feb, 2021 1 commit
  31. 28 Jan, 2021 1 commit
  33. 26 Jan, 2021 2 commits
  35. 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
  37. 21 Jan, 2021 2 commits
  39. 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
  41. 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
  43. 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
  45. 11 Jan, 2021 1 commit
  47. 07 Jan, 2021 1 commit
  49. 22 Dec, 2020 1 commit
  51. 10 Dec, 2020 1 commit
  53. 08 Dec, 2020 4 commits
  55. 26 Nov, 2020 1 commit