Skip to content

V
V8
Switch branch/tag
  1. 09 Mar, 2021 2 commits
    • 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
    • pthier's avatar
      Use map of prototype in Map::Hash. · ae882321
      pthier authored 
      Instead of using addresses of prototype and constructor (which can be
movedby GC) when computing the hash of a Map, we use the addresses of the
prototype map (which won't be compacted).
The prototype map is in a 1:1 relation with the prototype.
In addition the prototype points to the constructor in most cases.

Bug: v8:11519
Change-Id: Ibc47e5870955d7721509be07fae7719a93da9a26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739646
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73286}
      ae882321
  3. 08 Mar, 2021 7 commits
  5. 05 Mar, 2021 7 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. 03 Mar, 2021 6 commits
    • Benedikt Meurer's avatar
      [debug] Instantiate accessors only once. · e9873bf1
      Benedikt Meurer authored 
      When retrieving an API accessor function (i.e. either the getter or the
setter) for which the lazy accessor mechanism is used (i.e. where the
actual JSFunction is created lazily and only the FunctionTemplateInfo)
is around, we thus far created a fresh JSFunction every time the
accessor function is requested, but that's observably wrong behavior,
since the accessors are JavaScript objects with identity. We currently
rely on the instantiation cache to guarantee identity, but there's no
reason why we couldn't instead just put the instantiated JSFunction into
the AccessorPair.

Fixing this to only instantiate the lazy accessor pair only once, upon
first time it's requested, coincidentally also simplifies (and fixes)
the API accessor breakpoint machinery. This was previously lacking
support for walking dictionary prototype objects and forcibly
instantiating the lazy accessor pairs with break points. However, all
this magic in the debugger is no longer necessary when we ensure that
the lazy accessor pair component is generally only instantiated once.

Bug: v8:178, v8:7596, chromium:986063, chromium:496666
Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
Fixed: chromium:1163547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73163}
      e9873bf1
    • Camillo Bruni's avatar
      [api] Avoid handles for const API functions · aee471b2
      Camillo Bruni authored 
      Handles are notorious for preventing compiler optimizations. We should
avoid them for simple const functions.

- Mark more API functions const
- Mark more String functions const

Bug: v8:11195, chromium:808503, v8:11263
Change-Id: I9940e85600bc7d19027039d807b3313e2dcccdc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575065Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73159}
      aee471b2
    • Camillo Bruni's avatar
      [factory] Further dehandlify factory · 88bf5914
      Camillo Bruni authored 
      - Add private NewStructInternal
- Dehandlify JSObject initializers

Bug: v8:11263
Change-Id: I62d77ef32747c2042de707ba10fad20327af0930
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2729342Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73157}
      88bf5914
    • Frank Emrich's avatar
      [dict-proto] C++ implementation of SwissNameDictionary, pt. 8 · 50ee1407
      Frank Emrich authored 
      This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.

This CL contains:
1. Copy and equality functions used for testing
2. Runtime functions corresponding to most dictionary operations,
   which are used temporarily while the CSA/Torque implementation
   is work in progress
3. Some minor changes to SwissNameDictionary needed for testing
   (adding template instantiations, V8_EXPORT_PRIVATE, ...)

Bug: v8:11388
Change-Id: Iea5f4650b0a443edf563565138ea86fcb45af13a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2722094
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73153}
      50ee1407
    • Seth Brenith's avatar
      Privatize FixedArray-style accessors on ScopeInfo · 3a366c4d
      Seth Brenith authored 
      This is a partial reland of https://crrev.com/c/2601880 .

In preparation for ScopeInfo not being a FixedArrayBase, this change
privatizes the FixedArray-style functions that provide access to
ScopeInfo fields by index, and moves 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.

This change also introduces a new length() function in ScopeInfo which
hides the one inherited from FixedArrayBase and computes the ScopeInfo's
length based on its flags, so that there are no remaining readers of the
'length' field.

Change-Id: I609754010723b679e5cf00f386020faaab84c17a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718275
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73151}
      3a366c4d
    • Alex Kodat's avatar
      [api] Add StackFrame GetScriptSource and GetScriptSourceMappingURL · c613eb97
      Alex Kodat authored 
      These simplify production of extra information in stack traces or
dereferencing source maps in processing stack traces. While these
can be managed externally, this can be very complicated in
environments where scripts come from many different sources,
possibly not even under embedder control. Since V8 already has
easy access to this information, it's nice to share it with
embedders.

Bug: v8:11509
Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73148}
      c613eb97
  11. 02 Mar, 2021 2 commits
  13. 01 Mar, 2021 2 commits
  15. 26 Feb, 2021 2 commits
  17. 25 Feb, 2021 3 commits
  19. 24 Feb, 2021 7 commits