Skip to content

V
V8
Switch branch/tag
  1. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored 
      Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  3. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored 
      This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from

  serializeNaive: 10762 ms.
  serializeClever: 7813 ms.
  serializeConcat: 10271 ms.

to

  serializeNaive: 10278 ms.
  serializeClever: 5533 ms.
  serializeConcat: 10310 ms.

which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.

This was accomplished via a couple of different steps, which are briefly
outlined here:

  1. The empty_string gets its own map, so that we can easily recognize
     and handle it appropriately in the TurboFan type system. This
     allows us to express (and assert) that the inputs to NewConsString
     are non-empty strings, making sure that TurboFan no longer creates
     "crippled ConsStrings" with empty left or right hand sides.
  2. Further split the existing String types in TurboFan to be able to
     distinguish between OneByte and TwoByte strings on the type system
     level. This allows us to avoid having to dynamically lookup the
     resulting ConsString map in case of ConsString creation (i.e. when
     we know that both input strings are OneByte strings or at least
     one of the input strings is TwoByte).
  3. We also introduced more finegrained feedback for the Add bytecode
     in the interpreter, having it collect feedback about ConsStrings,
     specifically ConsOneByteString and ConsTwoByteString. This feedback
     can be used by TurboFan to only inline the relevant code for what
     was seen so far. This allows us to remove the Octane/Splay specific
     magic in JSTypedLowering to detect ConsString creation, and instead
     purely rely on the feedback of what was seen so far (also making it
     possible to change the semantics of NewConsString to be a low-level
     operator, which is only introduced in SimplifiedLowering by looking
     at the input types of StringConcat).
  4. On top of the before mentioned type and interpreter changes we added
     new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
     CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
     checks.

There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.

Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  5. 04 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete "one byte data hint" for strings. · 683cf6f4
      Benedikt Meurer authored 
      In the early days of Chrome when we used WebKit there was no support for
ASCII strings on the C++ side, so we put a hint onto these two-byte
strings that said "string only contains one byte data", such that
internally in V8 when these were involved in string operations, we could
instead create the *cheaper* one byte strings.

Nowadays Blink properly supports one-byte string representations and
this additional hint only comes with overhead, since we check it in
quite a few places (i.e. on the hot path for string concatenation), plus
we end up consuming more memory due to the additional string maps.
Removing the hint also frees one bit in the InstanceType zoo for
strings.

This alone improves performance on the `bench-dom-serialize.js` test case
by around **3%**.

Tbr: mstarzinger@chromium.org
Bug: v8:6622, v8:8834, v8:8939
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: I0753f2859cee7b5a37b6f0da64d8ec39fcb044ff
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/1498478
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60006}
      683cf6f4
  7. 13 Feb, 2019 1 commit
  9. 06 Feb, 2019 1 commit
  11. 01 Feb, 2019 2 commits
    • Michael Starzinger's avatar
      Revert "[serializer] share class positions tuple across contexts" · b1eb340d
      Michael Starzinger authored 
      This reverts commit a1b431d7.

Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/22809

Original change's description:
> [serializer] share class positions tuple across contexts
> 
> Class positions is a struct that stores the start and end positions of a class
> literal. It is stored both on class objects, and the template used to
> instantiate class objects.
> 
> The template is reachable from the bytecode array and therefore serialized by
> the startup serializer. Class objects are context-dependent and therefore
> serialized by the partial serializer. Serializing class positions from both
> serializers violates the assumption that we don't serialize any object twice.
> 
> R=​gsathya@chromium.org
> 
> Bug: v8:8761
> Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
> Reviewed-on: https://chromium-review.googlesource.com/c/1444956
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59292}

TBR=yangguo@chromium.org,mstarzinger@chromium.org,gsathya@chromium.org

Change-Id: I9f3fd1b29b5991b450223f8b27dfc7aa7e5a3171
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8761
Reviewed-on: https://chromium-review.googlesource.com/c/1450116Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59300}
      b1eb340d
    • Yang Guo's avatar
      [serializer] share class positions tuple across contexts · a1b431d7
      Yang Guo authored 
      Class positions is a struct that stores the start and end positions of a class
literal. It is stored both on class objects, and the template used to
instantiate class objects.

The template is reachable from the bytecode array and therefore serialized by
the startup serializer. Class objects are context-dependent and therefore
serialized by the partial serializer. Serializing class positions from both
serializers violates the assumption that we don't serialize any object twice.

R=gsathya@chromium.org

Bug: v8:8761
Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
Reviewed-on: https://chromium-review.googlesource.com/c/1444956Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59292}
      a1b431d7
  13. 30 Jan, 2019 1 commit
  15. 11 Jan, 2019 1 commit
  17. 29 Nov, 2018 1 commit
  19. 27 Nov, 2018 1 commit
  21. 26 Nov, 2018 1 commit
  23. 22 Nov, 2018 2 commits
  25. 21 Nov, 2018 2 commits
  27. 20 Nov, 2018 1 commit
  29. 13 Nov, 2018 1 commit
  31. 12 Nov, 2018 2 commits
  33. 05 Nov, 2018 1 commit
  35. 29 Oct, 2018 1 commit
  37. 19 Oct, 2018 1 commit
  39. 18 Oct, 2018 1 commit
  41. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored 
      This JSAsyncFunctionObject represents the implicit generator object
inside of async functions, and also holds the outer promise for the
async functions. This in turn allows us to get rid of the .promise
in the Parser / BytecodeGenerator completely, and will make it
possible to build zero-cost async stack traces independent of the
concrete synchronous part of the stack frame (which currently breaks
in Node.js).

In the bytecode all the async function operations now take this new
JSAsyncFunctionObject instead of passing both the .generator_object
and the .promise, which further simplifies and shrinks the bytecode.
It also reduces the size of async function frames, potentially making
the suspend/resume cheaper.

This also changes `await` to use intrinsics instead of calling to
special JSFunctions on the native context, and thus reduces the size of
the native contexts.

Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
to TurboFan.

Bug: v8:7253, v8:7522
Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1273049
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  43. 09 Oct, 2018 1 commit
  45. 05 Oct, 2018 1 commit
  47. 29 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Unify handling of await closure contexts. · 9e99297e
      Benedikt Meurer authored 
      Change the way that the (internal) await closures store the link to the
generator object by introducing a dedicated AwaitContext, which stores
the generator object into the extension slot (instead of misusing a
regular FunctionContext here). Also unify the allocation+initialization
of these contexts in the await-related builtins (both for async functions
and generators).

The rationale behind this is that for (zero-cost) async stack traces, we
will need to dig into these contexts and we can do better checking with
a dedicated instance type there. As an additional benefit, we save one
word per await context, since we just use (the otherwise unused) extension
slot to remember the generator object. As yet another benefit we will
never accidentally use any of these contexts in the regular scope chain
lookups, meaning we can also catch bugs there. And last but not least
the objects printing machinery understands these contexts now and can
even print the generator object for AwaitContexts for short printing,
which is really valuable for debugging.

Tbr: ulan@chromium.org
Bug: v8:7253, v8:7522, v8:8015
Change-Id: I86955f5701e694e8a10b91ebe5f52705aa90968d
Reviewed-on: https://chromium-review.googlesource.com/1249491Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56301}
      9e99297e
  49. 21 Sep, 2018 2 commits
  51. 10 Sep, 2018 1 commit
  53. 05 Sep, 2018 1 commit
  55. 04 Sep, 2018 2 commits
  57. 29 Aug, 2018 1 commit
  59. 27 Aug, 2018 1 commit
  61. 14 Aug, 2018 1 commit
  63. 08 Aug, 2018 1 commit
    • Sathya Gunasekaran's avatar
      [Intl] Optimize Intl.Collator · 363fe1eb
      Sathya Gunasekaran authored 
      This patch ports most of the Intl.Collator from JS to C++.

The Intl.Collator object no longer stores all the resolved
values. Instead these are looked up on demand as part of
Intl.Collator.prototype.resolvedOptions(), saving several words. In
the future, we can cache the result of the resolvedOptions as well.

In this patch, we use ICU to do parsing of the unicode extension in
the bcp47 language tag instead of using a custom extension parser.

This patch also fixes several spec compliance bugs as well.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Iaaa7be4a628404da1bd83d882e04a2c6de70ebd9
Bug: v8:5751, v8:7480
Reviewed-on: https://chromium-review.googlesource.com/1165084
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54965}
      363fe1eb
  65. 06 Aug, 2018 1 commit
    • Sathya Gunasekaran's avatar
      [Intl] Optimize Intl.PluralRules · cdb4d913
      Sathya Gunasekaran authored 
      Previously, Intl.PluralRules was mostly implemented in JavaScript. This
patch moves most of the constructor and parts of other methods to C++.

The size of the Intl.PluralRules object is reduced by not storing
MinimumIntegerDigits, MinimumFractionDigits, MaximumFractionDigits,
MinimumSignificantDigits, MaximumSignificantDigits. Instead these are
looked up from icu::DecimalFormat as required.

Another optimziation is that we don't create the result of
resolvedOptions when the Intl.PluralRules object is constructed, but
instead defer until this method is called. In the future, we may want
to cache the result.

This patch also cleans up several error handling paths that shouldn't
happen with ICU and instead just crashes should it ever happen.

Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I84c5aa6c25c35fe2d336693dee1b36bf3dcd4a79
Reviewed-on: https://chromium-review.googlesource.com/1158701
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJungshik Shin <jshin@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54917}
      cdb4d913
  67. 24 Jul, 2018 1 commit