Skip to content

V
V8
Switch branch/tag
  1. 12 Jun, 2015 1 commit
  3. 11 Jun, 2015 5 commits
  5. 08 Jun, 2015 3 commits
  7. 04 Jun, 2015 2 commits
    • arv's avatar
      [es6] super.prop, eval and lazy functions · 8c065681
      arv authored 
      We used to only store the uses_super_property in the preparse data
logger. Let the logger use NeedsHomeObject instead.

BUG=v8:3768
LOG=N
R=wingo, adamk

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

Cr-Commit-Position: refs/heads/master@{#28806}
      8c065681
    • 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
  9. 03 Jun, 2015 3 commits
  11. 02 Jun, 2015 6 commits
  13. 01 Jun, 2015 3 commits
  15. 29 May, 2015 1 commit
  17. 28 May, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Introduce prediction for exception handlers. · d8b94f34
      mstarzinger authored 
      This introduces a conservative prediction for each exception handler
whether it will locally catch an exception or re-throw it to outside
the code bondaries. It will allow for a more intuitive prediction of
whether an exception is considered "caught" or "uncaught".

R=bmeurer@chromium.org,yangguo@chromium.org
BUG=chromium:492522
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28681}
      d8b94f34
  19. 27 May, 2015 2 commits
  21. 26 May, 2015 1 commit
    • 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
  23. 22 May, 2015 5 commits
    • binji's avatar
      Implement SharedArrayBuffer. · aff8ebb0
      binji authored 
      This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.

Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.

LOG=N
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28594}
      aff8ebb0
    • yangguo's avatar
      Revert of Implement SharedArrayBuffer (patchset #7 id:120001 of... · 57ee3c0f
      yangguo authored 
      Revert of Implement SharedArrayBuffer (patchset #7 id:120001 of https://codereview.chromium.org/1136553006/)

Reason for revert:
breaks build

Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}

TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28589}
      57ee3c0f
    • binji's avatar
      Implement SharedArrayBuffer. · 57170bff
      binji authored 
      This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.

Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28588}
      57170bff
    • rossberg's avatar
      [strong] cache strong object literal maps · 65bea197
      rossberg authored 
      Also, add more literal tests.

R=dslomov@chromium.org
BUG=v8:3956
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28579}
      65bea197
    • mstarzinger's avatar
      Remove obsolete JSFunction::IsOptimizable predicate. · eb055cb3
      mstarzinger authored 
      This just delegates to SharedFunctionInfo::optimization_disabled and
was primarily used for assertions. Removing it due to misleading name
because already optimized functions reported being "non-optimizable".

This relands commit 181d7b85.

R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#28577}
      eb055cb3
  25. 21 May, 2015 7 commits