New issue
Advanced search Search tips

Issue 6991 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Oct 2017
HW: All
NextAction: ----
OS: All
Priority: 1
Type: Bug

issue 6936

Sign in to add a comment

Terrible deopt loop around property access in prettier benchmark

Project Member Reported by, Oct 24 2017

Issue description

The prettier test in the web-tooling-benchmark seems to suffer from a pretty heavy deoptimization loop around the access


where args can sometimes be a Smi. All of this is in the function printGenerically:

  function printGenerically(path, args) {
    const node = path.getValue();

    const shouldCache = node && typeof node === "object" && args === undefined;
    if (shouldCache && cache.has(node)) {
      return cache.get(node);

    const parent = path.getParentNode(0);
    // We let JSXElement print its comments itself because it adds () around
    // UnionTypeAnnotation has to align the child without the comments
    let res;
    if (
      ((node && node.type === "JSXElement") ||
        (parent &&
          (parent.type === "UnionTypeAnnotation" ||
            parent.type === "TSUnionType" ||
            ((parent.type === "ClassDeclaration" ||
              parent.type === "ClassExpression") &&
              parent.superClass === node)))) &&
    ) {
      res = genericPrint(path, options, printGenerically, args);
    } else {
      res = comments$3.printComments(
        p => genericPrint(p, options, printGenerically, args),
        args && args.needsSemi

    if (shouldCache) {
      cache.set(node, res);

    return res;

The problem seems to be on the TurboFan side. A simplified repro:

// Flags: --allow-natives-syntax --opt

function foo(o) { return o.x; }

assertEquals(undefined, foo({}));
assertEquals(undefined, foo(1));
assertEquals(undefined, foo({}));
assertEquals(undefined, foo(1));
assertEquals(undefined, foo({}));
assertEquals(undefined, foo(1));
13.1 MB View Download
7.3 MB View Download
355 KB View Download
Project Member

Comment 2 by, Oct 24 2017

The following revision refers to this bug:

commit a9da0ce73565a5b4357548686590cd0ae3735f68
Author: Benedikt Meurer <>
Date: Tue Oct 24 09:19:47 2017

[turbofan] Properly handle smis in monomorphic loads/stores.

When lowering a monomorphic load/store, where multiple receiver maps
have been recorded, but the action to be performed is the same (i.e.
yielding undefined because the property is not found), TurboFan used
to ignore the Smi case, leading to a pretty terrible deoptimization
loop, as the LOAD_IC/STORE_IC properly recorded that state and thus
didn't change it's state.

Fixing this issue gives a 18-20% boost on the prettier test of the
web-tooling-benchmark, which was suffering a lot from this problem.

Bug: v8:6936,  v8:6991 
Change-Id: Id208ec7129a7f6b190d989bda31f936040393226
Reviewed-by: Michael Stanton <>
Commit-Queue: Benedikt Meurer <>
Cr-Commit-Position: refs/heads/master@{#48865}

Status: Fixed (was: Started)

Sign in to add a comment