Skip to content

V
V8
Switch branch/tag
  1. 04 Oct, 2017 22 commits
  3. 03 Oct, 2017 7 commits
  5. 02 Oct, 2017 11 commits
    • Michael Starzinger's avatar
      [deoptimizer] Fix TranslatedState inline frame indexing. · 631489bd
      Michael Starzinger authored 
      This makes sure that helper methods on the {TranslatedState} class stick
to the counting scheme used by {OptimizedFrame::Summarize} within the
stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real
JavaScript frames.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-770543
BUG=chromium:770543

Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1
Reviewed-on: https://chromium-review.googlesource.com/695123
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48264}
      631489bd
    • Michael Starzinger's avatar
      [deoptimizer] Simplify {Runtime_NotifyDeoptimized} calls. · 1fa0f9ba
      Michael Starzinger authored 
      R=jarin@chromium.org

Change-Id: I6f2e70d231d2c28c77bee121e98317f3f506fce4
Reviewed-on: https://chromium-review.googlesource.com/691975
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48263}
      1fa0f9ba
    • Michael Starzinger's avatar
      [deoptimizer] Materialize objects with top-most stub frame. · 17d86d76
      Michael Starzinger authored 
      This makes sure the deoptimizer properly materializes heap objects, even
when the top-most frame happens to be a stub-frame. Without this step
the {arguments_marker} would leak into user-land and most likely be
treated as an undefined value.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-769852
BUG=chromium:769852

Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05
Reviewed-on: https://chromium-review.googlesource.com/691996Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48262}
      17d86d76
    • Benedikt Meurer's avatar
      [ic] Properly handle polymorphic symbol accesses. · 08db4d76
      Benedikt Meurer authored 
      Until now keyed accesses to properties with string or symbol keys were
only optimized properly while the IC was monomorphic and would go
megamorphic as soon as there's another receiver map, even if the name
was still the same (i.e. the same symbol or internalized string). This
was a weird performance-cliff, that'll hurt modern code especially
because for symbols you can only access them via keyed loads and stores.

This CL fixes the state machine inside the ICs to properly transition to
POLYMORPHIC state (and stay there) as long as the new name matches the
previously recorded name. The FeedbackVector and TurboFan were already
able to deal with this and didn't need any updates.

On the micro-benchmark from the tracking bug we go from

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 431 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 5621 ms.

to

  testStringMonomorphic: 429 ms.
  testSymbolMonomorphic: 429 ms.
  testStringPolymorphic: 429 ms.
  testSymbolPolymorphic: 430 ms.

effectively eliminating the overhead for symbols completely, and
yielding a 13.5x performance boost.

This also seems to yield a 1% improvement on the ARES6 ML benchmark,
because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups.

Bug: v8:6367, v8:6278, v8:6344
Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897
Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48261}
      08db4d76
    • Mathias Bynens's avatar
      [parser] Add use counter for U+2028 & U+2029 · d3c98121
      Mathias Bynens authored 
      The context is the following proposal to make JSON a subset of
JavaScript: https://github.com/tc39/proposal-json-superset

There’s interest in performing a side investigation to answer the
question of what would happen if we stopped treating U+2028 and U+2029
as `LineTerminator`s *entirely*. (Note that this is separate from the
proposal, which just changes how these characters are handled in
ECMAScript strings.) This is technically a breaking change, and IMHO it
would be wonderful if we could get away with it, but no one really has
any data on whether or not we could. Adding this use counter lets us get
that data.

BUG=v8:6827

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa
Reviewed-on: https://chromium-review.googlesource.com/693155
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48260}
      d3c98121
    • Michael Lippautz's avatar
      [heap] IncrementalMarking: Enforce coding style · 7283b57c
      Michael Lippautz authored 
      Bug: 
Change-Id: I2b1ae2f475e780606fa07db2cf861eb2537207d6
Reviewed-on: https://chromium-review.googlesource.com/695223Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48259}
      7283b57c
    • Camillo Bruni's avatar
      [tools] Increase limits to find stack messages in grokdump.py · 38c902de
      Camillo Bruni authored 
      Change-Id: I3b7e5f4fb9bc6cdad3582e19099fb97b2a0c7cb0
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/684185Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48258}
      38c902de
    • Benedikt Meurer's avatar
      [turbofan] Don't go MEGAMORPHIC when storing oddballs to typed arrays. · e65c0b25
      Benedikt Meurer authored 
      The KEYED_STORE_IC was never able to deal with stores to typed arrays
where the value being stored is not already a Number (i.e. either a Smi
or a HeapNumber). By extending it to also handle Oddballs (i.e. true,
false, undefined and null) and teaching TurboFan to also perform the
appropriate check plus the truncation to Number, we can easily support
this use case as well.

On the micro-benchmark in the bug report, we go from

  typedArrayStoreBool: 2975 ms.
  typedArrayStoreInt: 44 ms.

to

  typedArrayStoreBool: 43 ms.
  typedArrayStoreInt: 44 ms.

so that's roughly a 70x performance boost.

Bug: chromium:287773
Change-Id: I227419aeabc3f5b6793aa280a95448d03ac2f2dd
Reviewed-on: https://chromium-review.googlesource.com/691731
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48257}
      e65c0b25
    • Ben L. Titzer's avatar
      [wasm] Move memory-related methods to wasm-memory.(cc|h). · 9debe441
      Ben L. Titzer authored 
      R=gdeepti@chromium.org

Bug: 
Change-Id: Ic2e519d24354b3327a92daa0d4d6e06c9ca4605e
Reviewed-on: https://chromium-review.googlesource.com/687056
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48256}
      9debe441
    • Clemens Hammacher's avatar
      [wasm] Add flag for memory tracing · bfaacb8a
      Clemens Hammacher authored 
      With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.

R=titzer@chromium.org

Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}
      bfaacb8a
    • Benedikt Meurer's avatar
      [es2015] Optimize TypedArray.prototype[Symbol.toStringTag]. · b8b76eba
      Benedikt Meurer authored 
      The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with

  https://github.com/nodejs/node/pull/15663

for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.

The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from

  testIsArrayBufferView: 565 ms.
  testIsTypedArray: 2403 ms.
  testIsUint8Array: 3847 ms.

to

  testIsArrayBufferView: 566 ms.
  testIsTypedArray: 965 ms.
  testIsUint8Array: 965 ms.

which presents an up to 4x improvement.

Bug: v8:6874
Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48254}
      b8b76eba