v8/test/mjsunit/stack-traces-custom.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

67 lines
1.7 KiB
JavaScript
Raw Normal View History

// Copyright 2015 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
[stack-traces] Speed up method name inference. In JSStackFrame::GetMethodName() we try to infer a useful method name to show for the closure to which the stack frame belongs. This is done by first considering the functions name, and checking if the receiver has a property with that name and if that property's value is the closure. In case the function doesn't have a name or the property's value is not the closure itself, we fall back to a reverse lookup of the closure within the object (and its prototypes). This CL speeds up this logic by attacking two problems: 1. The reverse lookup was performed by first using the KeyAccumulator to extract the names of all enumerable properties, and afterwards using the LookupIterator on each name, and testing the resulting property value against the closure. This is fairly slow and creates a lot of temporary objects and handles. We now look into the descriptor arrays or dictionary backing stores of the objects directly instead, which is easily 2-10x faster. 2. For the common case of `o.foo = function() { ... }` the parser already places an "inferred name" of `o.foo` onto the SharedFunctionInfo, which we can use as a hint to infer the name of the function instead of immediately falling back to the expensive reverse lookup. This repairs the regression reported in http://crbug.com/1069425 and recovers most of the slowdown reported in http://crbug.com/1077657 (there's still some overhead left from the async stack trace tracking). Fixed: chromium:1069425 Bug: chromium:1077657 Change-Id: I88d23ccad123906df70c5217e815493106e03ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72545}
2021-02-05 13:11:26 +00:00
// Flags: --allow-natives-syntax
function testMethodNames(o) {
try {
o.k = 42;
} catch (e) {
Error.prepareStackTrace = function(e, frames) { return frames; };
var frames = e.stack;
Error.prepareStackTrace = undefined;
assertEquals("f", frames[0].getMethodName());
assertEquals(null, frames[1].getMethodName());
assertEquals("h1", frames[2].getMethodName());
assertEquals("j", frames[3].getMethodName());
assertEquals("k", frames[4].getMethodName());
assertEquals("testMethodNames", frames[5].getMethodName());
}
}
var o = {
f: function() { throw new Error(); },
[stack-traces] Speed up method name inference. In JSStackFrame::GetMethodName() we try to infer a useful method name to show for the closure to which the stack frame belongs. This is done by first considering the functions name, and checking if the receiver has a property with that name and if that property's value is the closure. In case the function doesn't have a name or the property's value is not the closure itself, we fall back to a reverse lookup of the closure within the object (and its prototypes). This CL speeds up this logic by attacking two problems: 1. The reverse lookup was performed by first using the KeyAccumulator to extract the names of all enumerable properties, and afterwards using the LookupIterator on each name, and testing the resulting property value against the closure. This is fairly slow and creates a lot of temporary objects and handles. We now look into the descriptor arrays or dictionary backing stores of the objects directly instead, which is easily 2-10x faster. 2. For the common case of `o.foo = function() { ... }` the parser already places an "inferred name" of `o.foo` onto the SharedFunctionInfo, which we can use as a hint to infer the name of the function instead of immediately falling back to the expensive reverse lookup. This repairs the regression reported in http://crbug.com/1069425 and recovers most of the slowdown reported in http://crbug.com/1077657 (there's still some overhead left from the async stack trace tracking). Fixed: chromium:1069425 Bug: chromium:1077657 Change-Id: I88d23ccad123906df70c5217e815493106e03ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72545}
2021-02-05 13:11:26 +00:00
get j() { o.h1(); },
set k(_) { o.j; },
};
[stack-traces] Speed up method name inference. In JSStackFrame::GetMethodName() we try to infer a useful method name to show for the closure to which the stack frame belongs. This is done by first considering the functions name, and checking if the receiver has a property with that name and if that property's value is the closure. In case the function doesn't have a name or the property's value is not the closure itself, we fall back to a reverse lookup of the closure within the object (and its prototypes). This CL speeds up this logic by attacking two problems: 1. The reverse lookup was performed by first using the KeyAccumulator to extract the names of all enumerable properties, and afterwards using the LookupIterator on each name, and testing the resulting property value against the closure. This is fairly slow and creates a lot of temporary objects and handles. We now look into the descriptor arrays or dictionary backing stores of the objects directly instead, which is easily 2-10x faster. 2. For the common case of `o.foo = function() { ... }` the parser already places an "inferred name" of `o.foo` onto the SharedFunctionInfo, which we can use as a hint to infer the name of the function instead of immediately falling back to the expensive reverse lookup. This repairs the regression reported in http://crbug.com/1069425 and recovers most of the slowdown reported in http://crbug.com/1077657 (there's still some overhead left from the async stack trace tracking). Fixed: chromium:1069425 Bug: chromium:1077657 Change-Id: I88d23ccad123906df70c5217e815493106e03ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72545}
2021-02-05 13:11:26 +00:00
const duplicate = function() { o.f() }
o.g1 = duplicate;
o.g2 = duplicate;
o.h1 = function() { o.g1() }
o.h2 = o.h1;
// Test in dictionary mode first.
assertFalse(%HasFastProperties(o));
testMethodNames(o);
// Same test but with fast mode object.
o = %ToFastProperties(o);
assertTrue(%HasFastProperties(o));
testMethodNames(o);
function testMethodName(f, frameNumber, expectedName) {
try {
Error.prepareStackTrace = function(e, frames) { return frames; }
f();
assertUnreachable();
} catch (e) {
const frame = e.stack[frameNumber];
assertEquals(expectedName, frame.getMethodName());
} finally {
Error.prepareStackTrace = undefined;
}
}
const thrower = { valueOf: () => { throw new Error(); }};
{
const str = "";
testMethodName(() => { str.indexOf(str, thrower); }, 1, "indexOf");
}
{
const nr = 42;
testMethodName(() => { nr.toString(thrower); }, 1, "toString");
}