Skip to content

V
V8
Switch branch/tag
  1. 19 Apr, 2017 1 commit
  3. 24 Mar, 2017 1 commit
  5. 17 Mar, 2017 1 commit
  7. 01 Mar, 2017 1 commit
  9. 20 Feb, 2017 1 commit
  11. 10 Feb, 2017 1 commit
  13. 13 Jan, 2017 3 commits
  15. 15 Nov, 2016 1 commit
    • petermarshall's avatar
      Fastpath some spread-call desugaring. · a63eeb48
      petermarshall authored 
      Avoid using the iterator for arrays with fast elements where the iterator has
not been modified.

Only deals with the case where there is a single spread argument.

Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.

BUG=v8:5511

Review-Url: https://codereview.chromium.org/2465253011
Cr-Commit-Position: refs/heads/master@{#40998}
      a63eeb48
  17. 04 Nov, 2016 1 commit
    • vogelheim's avatar
      V8 support for cached accessors. · cadcd787
      vogelheim authored 
      Some accessors requires little to no computation at all, its result can be
cached in a private property, avoiding the call overhead.
Calls to the getter are translated into a cheap property load.

Follow-on to crrev.com/2347523003, from peterssen@google.com

BUG=chromium:634276, v8:5548

Review-Url: https://codereview.chromium.org/2405213002
Cr-Commit-Position: refs/heads/master@{#40765}
      cadcd787
  19. 24 Oct, 2016 1 commit
  21. 21 Oct, 2016 4 commits
  23. 17 Oct, 2016 1 commit
  25. 26 Sep, 2016 1 commit
    • jgruber's avatar
      Enable component builds for fuzzers · 22606f0c
      jgruber authored 
      V8 is collecting a growing amount of fuzzers, all of which take substantial
space on the bots and in chromium build archives. This CL improves that
situation by allowing component (shared library) builds for almost all fuzzers.

The parser fuzzer is handled as an exception since it would require exporting a
large number of additional functions.

A component build results in about a 50-100x improvement in file size for each
fuzzer (~50M-100M to around 1.1M).

BUG=chromium:648864
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe

Review-Url: https://codereview.chromium.org/2360983002
Cr-Commit-Position: refs/heads/master@{#39709}
      22606f0c
  27. 06 Sep, 2016 1 commit
  29. 05 Sep, 2016 1 commit
  31. 01 Sep, 2016 1 commit
  33. 25 Jul, 2016 1 commit
  35. 07 Jul, 2016 1 commit
    • ishell's avatar
      [runtime] Better encapsulation of dictionary objects handling in lookup iterator. · 3fbb4521
      ishell authored 
      Now LookupIterator follows the same pattern of prepare transition, apply transition
and write value when adding new properties to dictionary objects.

JSGlobalObject case:
* Prepare transition phase ensures that there is a "transition" property cell
  prepared for receiving a value.
* Apply transition phase does nothing.
* Prepare for data property phase ensures that the existing property cell can
  receive the value.
* Write value phase writes value directly to the current property cell.

JSObject case:
* Prepare transition phase prepares the object for receiving a data value (which
  could switch an object to dictionary mode).
* Apply transition phase migrates object to a transition map. If the map happened
  to be a dictionary mode object's map then an uninitialized entry added to the
  properties dictionary.
* Prepare for data property phase does nothing.
* Write value phase just puts value to the properties dictionary.

BUG=chromium:576312

Review-Url: https://codereview.chromium.org/2127583002
Cr-Commit-Position: refs/heads/master@{#37585}
      3fbb4521
  37. 27 Jun, 2016 1 commit
  39. 24 Jun, 2016 1 commit
  41. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored 
      This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.

R=ishell@chromium.org
TBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n

Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  43. 13 May, 2016 1 commit
    • verwaest's avatar
      [runtime] Make sure that LookupIterator::OWN always performs a HIDDEN lookup as well. · c9a83150
      verwaest authored 
      Hidden prototypes are merely an implementation detail. Properties on an object + hidden prototype should look like properties on the object. Hence we should always perform a hidden prototype lookup. This CL removes the option to ignore hidden prototypes to avoid bugs that leak this implementation detail.

Also, the only previously valid cases were either places were we knew we didn't have a hidden prototype; or because we knew we (in the optimizing compiler) would only handle properties from the non-hidden object.The first case is already handled by directly tagging whether a receiver has a hidden prototype. In the second case we can just filter out properties from hidden prototypes.

Review-Url: https://codereview.chromium.org/1975763002
Cr-Commit-Position: refs/heads/master@{#36235}
      c9a83150
  45. 12 May, 2016 1 commit
  47. 04 May, 2016 1 commit
  49. 09 Mar, 2016 1 commit
  51. 07 Mar, 2016 1 commit
  53. 04 Mar, 2016 1 commit
  55. 03 Mar, 2016 1 commit
  57. 02 Mar, 2016 3 commits
  59. 22 Feb, 2016 1 commit
    • littledan's avatar
      Optimize @@species based on a global 'protector' cell · 7033ae51
      littledan authored 
      This patch makes ArraySpeciesCreate fast in V8 by avoiding two property reads
when the following conditions are met:
- No Array instance has had its __proto__ reset
- No Array instance has had a constructor property defined
- Array.prototype has not had its constructor changed
- Array[Symbol.species] has not been reset

For subclasses of Array, or for conditions where one of these assumptions is
violated, the full lookup of species is done according to the ArraySpeciesCreate
algorithm. Although this is a "performance cliff", it does not come up in the
expected typical use case of @@species (Array subclassing), so it is hoped that
this can form a good start. Array subclasses will incur the slowness of looking
up @@species, but their use won't slow down invocations of, for example,
Array.prototype.slice on Array base class instances.

Possible future optimizations:
- For the fallback case where the assumptions don't hold, optimize the two
  property lookups.
- For Array.prototype.slice and Array.prototype.splice, even if the full lookup
  of @@species needs to take place, we still could take the rest of the C++
  fastpath. However, to do this correctly requires changing the calling convention
  from C++ to JS to pass the @@species out, so it is not attempted in this patch.

With this patch, microbenchmarks of Array.prototype.slice do not suffer a
noticeable performance regression, unlike their previous 2.5x penalty.

TBR=hpayer@chromium.org

Review URL: https://codereview.chromium.org/1689733002

Cr-Commit-Position: refs/heads/master@{#34199}
      7033ae51
  61. 19 Feb, 2016 1 commit
  63. 18 Feb, 2016 1 commit
  65. 17 Feb, 2016 1 commit