Skip to content

V
V8
Switch branch/tag
  1. 01 Mar, 2016 1 commit
  3. 29 Feb, 2016 1 commit
  5. 17 Feb, 2016 2 commits
  7. 16 Feb, 2016 1 commit
  9. 05 Feb, 2016 1 commit
  11. 20 Jan, 2016 3 commits
  13. 19 Jan, 2016 2 commits
  15. 18 Jan, 2016 1 commit
  17. 13 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number constructor similar to String constructor. · 322ffda3
      bmeurer authored 
      Also migrate the Number constructor to a native builtin, using the
same mechanism already used by the String constructor. Otherwise just
parsing and compiling the Number constructor to optimized code already
eats 2ms on desktop for no good reason, and the resulting optimized
code is not even close to awesome.

Drive-by-fix: Use correct context for the [[Construct]] case of the
String constructor as well, and share some code with it.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33265}
      322ffda3
  19. 12 Jan, 2016 1 commit
  21. 08 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Object.keys to C++. · 50e1e751
      bmeurer authored 
      Everything necessary to implement Object.keys efficiently is already
available in C++ land for quite some time now, and only the thin
JavaScript wrapper was left, so get rid of that as well and move the
whole builtin to C++ instead.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33167}
      50e1e751
  23. 04 Jan, 2016 1 commit
  25. 30 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Migrate Object.create to C++. · 6a51d311
      bmeurer authored 
      There's no point in keeping the ObjectCreate JavaScript wrapper
function, which even does allocation site pretenuring for the
instances created via Object.create (where ObjectCreate itself is
the AllocationSite), and does not offer any sane way forward.

Instead introduce a new ObjectCreate C++ builtin, which currently
serves as a baseline implementation, on top of which we can think
about ways to optimize Object.create for the common case (i.e.
frameworks such as Ember.js make heavy use of Object.create).

R=cbruni@chromium.org
TBR=hpayer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33061}
      6a51d311
  27. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored 
      According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}

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

Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored 
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )

Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind

Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}

TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629

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

Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  29. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored 
      According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.

There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.

The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea
  31. 22 Dec, 2015 5 commits
  33. 21 Dec, 2015 1 commit
    • cbruni's avatar
      [proxies] Better print for proxies in d8 · 8bfb7189
      cbruni authored 
      Function proxies would not be printed so far since they ended up in Function.prototype.toString which only works with Function as a receiver but no Proxy. Additionally added support for more gracefully dealing with recursive __proto__ structures introduced by proxies.

BUG=v8:1543
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32985}
      8bfb7189
  35. 17 Dec, 2015 2 commits
  37. 14 Dec, 2015 1 commit
    • neis's avatar
      [proxies] Improve error messages. · e9606365
      neis authored 
      This CL makes proxy-related error messages more accurate and verbose.
(Exception: those used in deprecated functions in v8natives.js.)  Some of
the old error messages were simply wrong.

On the side, fix ShouldThrow semantics of JSProxy::SetPrototype and
JSProxy::DefineOwnProperty.

R=cbruni@chromium.org, jkummerow@chromium.org
BUG=v8:1543
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32836}
      e9606365
  39. 11 Dec, 2015 3 commits
  41. 10 Dec, 2015 2 commits
  43. 08 Dec, 2015 1 commit
  45. 07 Dec, 2015 3 commits
  47. 04 Dec, 2015 2 commits