Skip to content

V
V8
Switch branch/tag
  1. 08 Jun, 2015 3 commits
    • mvstanton's avatar
      Vector ICs: ClassLiterals need to allocate a vector slot for home objects. · b27016b7
      mvstanton authored 
      BUG=

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

Cr-Commit-Position: refs/heads/master@{#28827}
      b27016b7
    • jarin's avatar
      Unify decoding of deoptimization translations. · 9127d4ee
      jarin authored 
      This unifies methods Deoptimizer::DoTranslateCommand, Deotpimizer::DoTranslateObject and the arguments object materializer.

To unify these, we have to separate reading of the input frame from writing to the output frame because the argument materializer does not write to output frames.

Instead, we now deoptimize in following stages:

1. Read out the input frame/registers, decode them using the translations from the deoptimizer and store them in the deoptimizer (Deoptimizer::translated_state_). This is done in TranslatedState::Init.

2. Write out into the output frame buffer all the values that do not require allocation. We also remember references to the values that require materialization. As before, this is done in Deoptimizer::DoCompute*Frame method, but instead calling to DoTranslateCommand, we use the translated frame to obtain the values and write them to the output frames.

3. The platform specific code then sets up the output frames and calls into the deoptimization notification. This has not been changed at all.

4. Once the stack is setup, we handlify all the references in the saved translated values (TranslatedState::Prepare).

5. Finally, we materialize all the values we remembered in step (1) and write them to their frames on the stack (using the TranslatedValue::GetValue method).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28826}
      9127d4ee
    • mvstanton's avatar
      Vector ICs: debugger should save registers for vector store ics. · bd32a9f7
      mvstanton authored 
      BUG=
R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28825}
      bd32a9f7
  3. 04 Jun, 2015 2 commits
    • arv's avatar
      Refactor lexical home object binding · 345fa142
      arv authored 
      Before this we had 3 super related lexical bindings that got injected
into method bodies: .home_object, .this_function,  and new.target.
With this change we get rid of the .home_object one in favor of using
.this_function[home_object_symbol] which allows some simplifications
throughout the code base.

BUG=v8:3768
LOG=N
R=adamk@chromium.org, wingo@igalia.com

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

Cr-Commit-Position: refs/heads/master@{#28802}
      345fa142
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  5. 03 Jun, 2015 3 commits
    • mstarzinger's avatar
      Fix arrow functions requiring context without slots. · 68beef53
      mstarzinger authored 
      This fixes a corner-case where arrow functions that require a context
allocate none, because there are no additional slots allocated. Note
that this didn't happen with true function scopes because they always
had at least the receiver slot.

The outcome was a context chain that no longer was in sync with the
scope chain, hence context slot loads were bogus. This is observable
using the DYNAMIC_LOCAL optimization in all compilers.

R=rossberg@chromium.org,wingo@igalia.com
TEST=mjsunit/harmony/regress/regress-4160
BUG=v8:4160
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28788}
      68beef53
    • bmeurer's avatar
      [date] Refactor the %_DateField intrinsic to be optimizable. · e4782a9b
      bmeurer authored 
      Previously the %_DateField intrinsic would also check the object and
throw an exception if you happen to pass something that is not a valid
JSDate, which (a) violates our policy for instrinsics and (b) is hard to
optimize in TurboFan (even Crankshaft has a hard time, but there we will
never inline the relevant builtins, so it doesn't show up). The throwing
part is now a separate intrinsics %_ThrowIfNotADate that throws an
exception in full codegen and deoptimizes in Crankshaft, which means the
code for the current use cases is roughly the same (modulo some register
renamings/gap moves).

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28782}
      e4782a9b
    • bmeurer's avatar
      Revert of Embedded constant pools. (patchset #12 id:220001 of... · 51439db3
      bmeurer authored 
      Revert of Embedded constant pools. (patchset #12 id:220001 of https://codereview.chromium.org/1131783003/)

Reason for revert:
Breaks Linux nosnap cctest/test-api/FastReturnValuesWithProfiler, see http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/609/steps/Check/logs/FastReturnValuesWithP..

Original issue's description:
> Add support for Embedded Constant Pools for PPC and Arm
>
> Embed constant pools within their corresponding Code
> objects.
>
> This removes support for out-of-line constant pools in favor
> of the new approach -- the main advantage being that it
> eliminates the need to allocate and manage separate constant
> pool array objects.
>
> Currently supported on PPC and ARM.  Enabled by default on
> PPC only.
>
> This yields a 6% improvment in Octane on PPC64.
>
> R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
> BUG=chromium:478811
> LOG=Y
>
> Committed: https://crrev.com/a9404029343d65f146e3443f5280c40a97e736af
> Cr-Commit-Position: refs/heads/master@{#28770}

TBR=rmcilroy@chromium.org,ishell@chromium.org,rodolph.perfetta@arm.com,mbrandy@us.ibm.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:478811

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

Cr-Commit-Position: refs/heads/master@{#28772}
      51439db3
  7. 02 Jun, 2015 4 commits
  9. 01 Jun, 2015 4 commits
  11. 29 May, 2015 1 commit
  13. 28 May, 2015 1 commit
  15. 27 May, 2015 1 commit
  17. 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
  19. 22 May, 2015 1 commit
  21. 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
  23. 20 May, 2015 2 commits
  25. 19 May, 2015 3 commits
  27. 18 May, 2015 1 commit
  29. 15 May, 2015 1 commit
  31. 13 May, 2015 1 commit
  33. 12 May, 2015 2 commits
  35. 11 May, 2015 4 commits
  37. 08 May, 2015 1 commit