Skip to content

V
V8
Switch branch/tag
  1. 28 May, 2015 1 commit
  3. 27 May, 2015 1 commit
  5. 26 May, 2015 4 commits
    • arv's avatar
      [es6] Support super.property in eval and arrow functions · 44e98103
      arv authored 
      When we enter a method that needs access to the [[HomeObject]]
we allocate a local variable `.home_object` and assign it the
value from the [[HomeObject]] private symbol. Something along
the lines of:

  method() {
    var .home_object = %ThisFunction()[home_object_symbol];
    ...
  }

BUG=v8:3867, v8:4031
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28644}
      44e98103
    • erikcorry's avatar
      Move hash code from hidden string to a private symbol · eca5b5d7
      erikcorry authored 
      * Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code.  The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++.  Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.

Performance figures are in the comments to the code review.  Summary: Most of js-perf-test/Collections is neutral.  Set and Map with object keys are 40-50% better.  WeakMap is -5% and WeakSet is +9%.  After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.

In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this.  Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately).  With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.

In a similar vein we could give the magic zero hash code to the hash code
symbol.  Then when we look up the hash code we would sometimes see the table
with all the hidden properties.  This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it.  I'd be loath to bring it back.  On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.

One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS.  I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.

R=adamk@chromium.org, verwaest@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28622}
      eca5b5d7
    • mvstanton's avatar
      Move work to omit unnecessary ObjectLiteral stores to the numbering pass. · 32de6778
      mvstanton authored 
      The reason is that this information will be needed to compute the number of
vector ic slots done at numbering time.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28615}
      32de6778
    • yangguo's avatar
      Do not leak message object beyond try-catch. · 14eba9b2
      yangguo authored 
      R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28612}
      14eba9b2
  7. 22 May, 2015 1 commit
  9. 21 May, 2015 1 commit
    • arv's avatar
      [es6] Spread in array literals · 9502e91a
      arv authored 
      This allows you to put iterables into your array literals
and the will get spread into the array.

  let x = [0, ...range(1, 3)];  // [0, 1, 2]

This is done by treating the array literal up to the first
spread element as usual, including using a boiler plate
array, and then appending the remaining expressions and rest
expressions.

BUG=v8:3018
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28534}
      9502e91a
  11. 20 May, 2015 3 commits
  13. 19 May, 2015 3 commits
  15. 18 May, 2015 2 commits
  17. 15 May, 2015 2 commits
  19. 13 May, 2015 1 commit
  21. 12 May, 2015 2 commits
  23. 11 May, 2015 4 commits
  25. 08 May, 2015 1 commit
  27. 07 May, 2015 2 commits
    • verwaest's avatar
      Allow loading holes from holey smi arrays · eab5bb53
      verwaest authored 
      BUG=

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

Cr-Commit-Position: refs/heads/master@{#28298}
      eab5bb53
    • machenbach's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 5cab6be8
      machenbach authored 
      Revert of Resolve references to "this" the same way as normal variables (patchset #2 id:20001 of https://codereview.chromium.org/1130733003/)

Reason for revert:
[Sheriff] Breaks jetstream benchmark with errors like this:

>>> Running suite: JetStream/bigfib.cpp
>>> Stdout (#1):
undefined:93: ReferenceError: this is not defined
  this['Module'] = Module;
  ^
ReferenceError: this is not defined
    at eval (eval at __run (runner.js:13:3), <anonymous>:93:3)
    at eval (native)
    at __run (runner.js:13:3)
    at Object.runSimpleBenchmark (runner.js:44:31)
    at runner.js:97:13

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=v8:2700
> LOG=N
>
> Committed: https://crrev.com/06a792b7cc2db33ffce7244c044a9c05afbb6116
> Cr-Commit-Position: refs/heads/master@{#28263}

TBR=rossberg@chromium.org,arv@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2700

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

Cr-Commit-Position: refs/heads/master@{#28283}
      5cab6be8
  29. 06 May, 2015 5 commits
  31. 05 May, 2015 6 commits
    • dslomov's avatar
      Handle the case when derived constructor is [[Call]]ed with 0 args. · cf53fed9
      dslomov authored 
      ArgumentsAdaptorStub for derived constructor (the one that needs
new.target) works in this way:
 - If the constructor is invoked via the Construct stub, we know that
   actual arguments always include new.target. ``arguments`` object
   however should not include a new.target, therefore we remove it.
   We achieve this by decrementing the argument count.
 - If the constructor is invoked as a call, we do not care for a correct
   ``arguments`` array since the constructor will immediately throw on
   entrance.
The bug is that the call could actually pass 0 actual arguments, but I
decrement unconditionally :(. The fix is to detect this case and avoid
decrementing. ``arguments`` is bogus, but it is ok as constructor
throws.

Long-term we should just remove mucking about with arguments for
new.target and just get it from the stack.

R=arv@chromium.org,rossberg@chromium.org
BUG=chromium:474783
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28242}
      cf53fed9
    • wingo's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 1e4173d9
      wingo authored 
      Revert of Resolve references to "this" the same way as normal variables (patchset #11 id:240001 of https://codereview.chromium.org/1097283003/)

Reason for revert:
nosnap failures

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=
> LOG=N
>
> Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
> Cr-Commit-Position: refs/heads/master@{#28236}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28238}
      1e4173d9
    • danno's avatar
      Revert of Collect type feedback on result of Math.[round|ceil|floor] (patchset... · a988d5f2
      danno authored 
      Revert of Collect type feedback on result of Math.[round|ceil|floor] (patchset #13 id:230001 of https://codereview.chromium.org/1053143005/)

Reason for revert:
All sorts of performance regressions

Original issue's description:
> Collect type feedback on result of Math.[round|ceil|floor]
>
> By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
>
> Committed: https://crrev.com/f36ecaf3a4d61568ca50a20718acce7dd5da9a5f
> Cr-Commit-Position: refs/heads/master@{#28215}

TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#28237}
      a988d5f2
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 18619d35
      wingo authored 
      Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.

Based on work by Adrian Perez de Castro <aperez@igalia.com>.

BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28236}
      18619d35
    • arv's avatar
      [es6] When comparing two symbols we may need to throw a TypeError · d26f5d39
      arv authored 
      When comparing a symbol to istself using <, <=, > or >= we need to
throw a TypeError. This is correctly handled in the runtime function
so if we are comparing a symbol fall back to use the runtime.

BUG=v8:4073
LOG=Y
R=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28226}
      d26f5d39
    • danno's avatar
      Collect type feedback on result of Math.[round|ceil|floor] · f36ecaf3
      danno authored 
      By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.

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

Cr-Commit-Position: refs/heads/master@{#28215}
      f36ecaf3
  33. 04 May, 2015 1 commit