Commit Graph

3 Commits

Author SHA1 Message Date
Benedikt Meurer
bcee140617 [turbofan] Introduce InstanceOfIC to collect rhs feedback.
This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
constant feedback about the right-hand side of instanceof operators,
including both JSFunction and JSBoundFunction instances. TurboFan then
uses the feedback to optimize instanceof in places where the right-hand
side is not a known constant (known to TurboFan).

This addresses the odd performance cliff that we see with instanceof in
functions with multiple closures. It was discovered as one of the main
bottlenecks on the uglify-es test in the web-tooling-benchmark. The
uglify-es test (run in separation) is ~18% faster with this change.

On the micro-benchmark in the tracking bug we go from

  instanceofSingleClosure_Const: 69 ms.
  instanceofSingleClosure_Class: 246 ms.
  instanceofMultiClosure: 246 ms.
  instanceofParameter: 246 ms.

to

  instanceofSingleClosure_Const: 70 ms.
  instanceofSingleClosure_Class: 75 ms.
  instanceofMultiClosure: 76 ms.
  instanceofParameter: 73 ms.

boosting performance by roughly 3.6x and thus effectively removing the
performance cliff around instanceof.

Bug: v8:6936, v8:6971
Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
Reviewed-on: https://chromium-review.googlesource.com/730686
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 10:15:36 +00:00
bmeurer
c9c7dd0d4e [turbofan] Constant-fold certain JSOrdinaryHasInstance nodes.
Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
which was previously mostly done in JSTypedLowering (for no reason).
Add new logic to the lowering to constant-fold OrdinaryHasInstance
checks when the map of the left-hand side and the "prototype" of the
right-hand side is known. This address the performance issue with the
(base) class constructors generated by Babel, i.e.:

  function _classCallCheck(instance, Constructor) {
    if (!(instance instanceof Constructor)) {
      throw new TypeError("Cannot call a class as a function");
    }
  }

  var C = function C() { _classCallCheck(this, C); };

for

  class C {}

Also ensure that a known constructor being used inside an instanceof
get's a proper initial map on-demand.

BUG=v8:6275
R=mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2827013002
Cr-Commit-Position: refs/heads/master@{#44727}
2017-04-19 14:38:11 +00:00
bmeurer
241c024c10 [turbofan] Properly optimize instanceof (even in the presence of @@hasInstance).
This is the TurboFan counterpart of http://crrev.com/2504263004, but it
is a bit more involved, since in TurboFan we always inline the appropriate
call to the @@hasInstance handler, and by that we can optimize a lot more
patterns of instanceof than Crankshaft, and even yield fast instanceof
for custom @@hasInstance handlers (which we can now properly inline as
well).

Also we now properly optimize Function.prototype[@@hasInstance], even if
the right hand side of an instanceof doesn't have the Function.prototype
as its direct prototype.

For the baseline case, we still rely on the global protector cell, but
we can address that in a follow-up as well, and make it more robust in
general.

TEST=mjsunit/compiler/instanceof
BUG=v8:5640
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2511223003
Cr-Commit-Position: refs/heads/master@{#41092}
2016-11-18 06:31:42 +00:00