Skip to content

V
V8
Switch branch/tag
  1. 07 Nov, 2017 1 commit
  3. 31 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Add OOB support to KeyedLoadIC. · 6dc35ab4
      Benedikt Meurer authored 
      This adds support to the KeyedLoadIC to ignore out of bounds accesses
for Strings and return undefined instead. We add a dedicated bit to the
Smi handler to encode the OOB state and have TurboFan generate appropriate
code for that case as well. This is mostly useful when programs
accidentially access past the length of a string, which was observed and
fixed for example in Babel recently, see

  https://github.com/babel/babel/pull/6589

for details. The idea is to also extend this mechanism to Arrays and
maybe other receivers, as reading beyond the length is also often used
in jQuery and other popular libraries.

Note that this is considered a mitigation for a performance cliff and
not a general optimization of OOB accesses. These should still be
avoided and handled properly instead.

This seems to further improve the babel test on the web-tooling-benchmark
by around 1%, because the OOB access no longer turns the otherwise
MONOMORPHIC access into MEGAMORPHIC state.

Bug: v8:6936, v8:7014
Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
Reviewed-on: https://chromium-review.googlesource.com/744022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49049}
      6dc35ab4
  5. 24 Oct, 2017 1 commit
    • Daniel Clifford's avatar
      Reimplement Array.prototype.slice in CSA and C++ · 6452b26a
      Daniel Clifford authored 
      Previously, V8's slice was implemented in a combination of C++ and a 
Javascript fallback. The disadvantage of this approach was that the
fast-path required a call through the CEntryStub, which introduced
considerable overhead for small arrays with fast elements kinds.

Now the implementation primarily uses the CSA to generate both the
full spec-complaint implementation as well as fast paths for argument
objects and arrays with fast elements kinds. The CSA implementation
uses a C++ implementation fallback in select situations where the the
complexity of a CSA implementation would be too great and the
CEntryStub overhead is not decisive (e.g. slices of dictionary
elements arrays).

Performance results on semi-random arrays with small number of
elements (old vs. new):

smi copy: 48.7 ms vs. 12 ms
smi slice: 43.5 ms 14.8 ms
object copy: 35.5 ms 7.7 ms
object slice: 38.7 ms 8.8 ms
dictionary slice: 2398.3 ms vs. 5.4 ms
fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
slow sloppy arguments slice: 28.9 ms vs. 8.5 ms

As a bonus, the new implementation is fully spec-compliant and fixes
at least one existing bug.

The design document for Array.prototype builtin rework can be found
at https://goo.gl/wFHe2n

Bug: v8:1956,v8:6601,v8:6710,v8:6978
Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
Reviewed-on: https://chromium-review.googlesource.com/574710
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48853}
      6452b26a
  7. 23 Oct, 2017 1 commit
  9. 19 Oct, 2017 1 commit
  11. 18 Oct, 2017 1 commit
  13. 13 Oct, 2017 1 commit
  15. 11 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Add fast-path for JSTypedArray to CreateListFromArrayLike. · f31bae03
      Benedikt Meurer authored 
      It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.

  String.fromCharCode.apply(undefined, uint8array)

is seen quite often on the web. But there are other interesting cases
like

  Math.max.apply(undefined, float64array)

to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.

This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from

  stringFromCharCode: 6386 ms.
  stringFromCodePoint: 8752 ms.

to

  stringFromCharCode: 1932 ms.
  stringFromCodePoint: 4262 ms.

which corresponds to a 2.0x-3.3x improvement.

Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
      f31bae03
  17. 05 Sep, 2017 1 commit
    • Franziska Hinkelmann's avatar
      [api] Use query interceptor in Object.keys(). · 43bb2778
      Franziska Hinkelmann authored 
      The V8 API provides interceptors. They are not part of the
EcmaScript specification. But their behavior should be consistent.
For example, when an EnumeratorInterceptor is defined, Object.keys(),
Object.entries(), and Object.values() should all have the
same number of entries.

This CL creates consistent behavior among these
functions. If a QueryCallback is present, it is used to
filter the result from the EnumeratorCallback for
enumerable properties.

Bug: v8:6627
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4f4271ddeb99a5e85918148c5033923c149b9468
Reviewed-on: https://chromium-review.googlesource.com/649786Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47831}
      43bb2778
  19. 22 Aug, 2017 1 commit
  21. 18 Aug, 2017 1 commit
    • Franziska Hinkelmann's avatar
      [api] Use query interceptor in Object.keys(). · b6059a67
      Franziska Hinkelmann authored 
      The V8 API provides interceptors. They are not part of the
EcmaScript specification. But their behavior should be consistent.
For example, when an EnumeratorInterceptor is defined, Object.keys(),
Object.entries(), and Object.values() should all have the
same number of entries.

This CL creates consistent behavior among these
functions. If a QueryCallback is present, it is used to
filter the result from the EnumeratorCallback for
enumerable properties.

Bug: v8:6627
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie51e69bb77099d9fafc4b1ea02671eced610edba
Reviewed-on: https://chromium-review.googlesource.com/609068Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47442}
      b6059a67
  23. 04 Aug, 2017 1 commit
  25. 02 Aug, 2017 1 commit
  27. 12 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      Define symbols properly · a52b9cd8
      Clemens Hammacher authored 
      The problem popped up when passing the constants by reference
(https://chromium-review.googlesource.com/c/565141).
It's a bit ugly, but, the C++11 standard requires a definition
additionally to the existing declaration in the body of the class:

9.4.2/4: If a static data member is of const literal type, its
  declaration in the class definition can specify a
  brace-or-equal-initializer in which every initializer-clause that is
  an assignment-expression is a constant expression. A static data
  member of literal type can be declared in the class definition with
  the constexpr specifier; if so, its declaration shall specify a
  brace-or-equal-initializer in which every initializer-clause that i
  an assignment-expression is a constant expression. [Note: In both
  these cases, the member may appear in constant expressions. — end
  note] The member shall still be defined in a namespace scope if it is
  odr-used (3.2) in the program and the namespace scope definition shall
  not contain an initializer.

Drive-by: Make the static constants constexpr.

R=bmeurer@chromium.org

Change-Id: Idc3d20bf2adf31d874c23ff8bfec52437789160a
Reviewed-on: https://chromium-review.googlesource.com/567506Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46599}
      a52b9cd8
  29. 10 Jul, 2017 1 commit
  31. 06 Jul, 2017 1 commit
  33. 03 Jul, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename Has*Elements and Is*ElementsKind methods · 7915cf93
      Mathias Bynens authored 
      Commit 26c00f4a improved the names of
most FAST_* elements kinds in the enum. This patch updates the matching
Has*Elements and Is*ElementsKind method names accordingly.

- HasFastSmiElements => HasSmiElements
- IsFastSmiElementsKind => IsSmiElementsKind
- HasFastObjectElements => HasObjectElements
- IsFastObjectElementsKind => IsObjectElementsKind
- HasFastSmiOrObjectElements => HasSmiOrObjectElements
- IsFastSmiOrObjectElementsKind => IsSmiOrObjectElementsKind
- HasFastDoubleElements => HasDoubleElements
- IsFastDoubleElementsKind => IsDoubleElementsKind
- HasFastHoleyElements => HasHoleyElements
- IsFastHoleyElementsKind => IsHoleyElementsKind

Additionally, FastHoleyElementsUsage is renamed to HoleyElementsUsage.

BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie8f3d01eb43e909cbc6c372d88c5fbc4dfc2ac04
Reviewed-on: https://chromium-review.googlesource.com/558356Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46376}
      7915cf93
  35. 30 Jun, 2017 2 commits
  37. 27 Jun, 2017 1 commit
  39. 26 Jun, 2017 1 commit
  41. 23 Jun, 2017 2 commits
  43. 22 Jun, 2017 3 commits
  45. 21 Jun, 2017 2 commits
  47. 12 Jun, 2017 1 commit
  49. 29 May, 2017 1 commit
  51. 22 May, 2017 1 commit
  53. 16 May, 2017 2 commits
    • Jakob Kummerow's avatar
      [elements] Fix pathological slowness when deleting many elements · 6aaccd0f
      Jakob Kummerow authored 
      When most elements of an object are deleted, we want to normalize its
elements backing store to a dictionary in order to save space. Finding
the right time to do so should not incur a linear cost on each delete
operation. This patch changes the heuristic to an amortized-constant
approach based on a global counter and the current backing store
capacity.

BUG=chromium:542978

Change-Id: Ifdf29ab2211fdde1df9078f63be4118627d6a67e
Reviewed-on: https://chromium-review.googlesource.com/506191Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45330}
      6aaccd0f
    • Tobias Tebbi's avatar
      [runtime] avoid trim/grow loop when adding and removing one element · cd33ec55
      Tobias Tebbi authored 
      We currently grow the backing store to (old_capacity*1.5)+16 if we exceed capacity, 
but shrink the capacity to the current length when 2*length <= capacity.
For short arrays (up to length 32), this can lead to a copy on every operation when using push/pop or push/shift.

Example:
Array of length 32, capacity 32
push
Array grown to length 33, capacity 32*1.5+16 = 64
pop
Array trimmed to length 32, capacity 32 because 2*32 <= 64
...

This CL leaves additional slag space when calling pop and restricts the trimming to backing stores with at least 16 elements to prevent excessive re-trimming on short arrays.

Bug: 
Change-Id: I9dd13e5e2550c7ac819294c8e29f04c8855e02a4
Reviewed-on: https://chromium-review.googlesource.com/502911
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45324}
      cd33ec55
  55. 15 May, 2017 1 commit
  57. 10 May, 2017 1 commit
  59. 05 May, 2017 1 commit
  61. 02 May, 2017 1 commit
    • Peter Marshall's avatar
      [builtins] Fix overly strict CHECK in TypedArray.Set. · 0d582ada
      Peter Marshall authored 
      The existing CHECK assumed that the source and destination could not
have the same buffer, but they actually can as long as the data
ranges do not overlap within the buffer. Change the check to look for
this more relaxed condition instead.

Moved the check outside of the memcpy case as well, given that it
should also apply for the slower, element-by-element copy as well.

Also use JSTypedArray::element_size() to get the element size instead
of the helper on the FixedTypedArrayBase. This lets us change that
helper back to private again.

Bug: chromium:717022

Change-Id: I2eca1df1e87444c5db397e0b7cf686cefe67d29c
Reviewed-on: https://chromium-review.googlesource.com/493147
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45035}
      0d582ada
  63. 27 Apr, 2017 1 commit
  65. 26 Apr, 2017 1 commit
  67. 25 Apr, 2017 1 commit