Changeset 155657 in webkit for trunk/Source/JavaScriptCore/bytecompiler

Timestamp:

Sep 12, 2013, 4:07:36 PM (12 years ago)

Author:

[email protected]

Message:

Source/JavaScriptCore: Web Inspector shouldn't artificially allocate the arguments object in functions that don't use it
​https://bugs.webkit.org/show_bug.cgi?id=121206
<rdar://problem/6911886>

Reviewed by Joseph Pecoraro.

This is a step toward better tools, and a 23% speedup in a simple
JavaScript benchmark run with the Web Inspector open.

We want the Web Inspector to be fast, and we want it to produce reliable
CPU and memory profiles. We can't do that if just opening the Web Inspector
incurs huge CPU/memory penalties like the arguments object.

Also, since use of the 'arguments' identifier is an API for allocating
an object, I think it's good for the UI to let developers know when
they've invoked that API and when they haven't.

• bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::BytecodeGenerator): No need to allocate the
arguments object artificially for the debugger's sake. The activation
object no longer assumes that the stack frame is laid out for one.

(Long-term, this code will move out of the activation object, into a
special object for interfacing with the debugger.)

• runtime/JSActivation.cpp:

(JSC::JSActivation::getOwnNonIndexPropertyNames):
(JSC::JSActivation::getOwnPropertySlot): Don't advertise or provide an
arguments object if the user function didn't include one. The bytecode
generator will not have laid out the stack frame to support one.

(Eventually, we do want the Web Inspector to see an arguments
object in scope in the console. That's a one-line change in JSActivation,
but it's blocked by ​https://bugs.webkit.org/show_bug.cgi?id=121208.)

(JSC::JSActivation::argumentsGetter):

• runtime/JSActivation.h: Removed this obsolete performance

work-around. C++ property access to an activation object is no longer
hot.

LayoutTests: Web Inspector shouldn't artificially allocate the arguments object in functions that don't use it
​https://bugs.webkit.org/show_bug.cgi?id=121206

Reviewed by Joseph Pecoraro.
<rdar://problem/6911886>

• inspector/debugger/debugger-expand-scope-expected.txt: Updated these

results to reflect the fact that it's correct to exclude the 'arguments'
identifier from function scopes that don't use it.

• inspector/debugger/debugger-expand-scope.html: Edited this test to

include one frame that uses the 'arguments' identifier and one frame
that doesn't, so we test both cases.

File:

• trunk/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp (modified) (2 diffs)

trunk/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp

@@ -226 +226 @@
     m_symbolTable->setCaptureStart(m_codeBlock->m_numVars);
 
-    if (functionBody->usesArguments() || codeBlock->usesEval() || m_shouldEmitDebugHooks) { // May reify arguments object.
+    if (functionBody->usesArguments() || codeBlock->usesEval()) { // May reify arguments object.
         RegisterID* unmodifiedArgumentsRegister = addVar(); // Anonymous, so it can't be modified by user code.
         RegisterID* argumentsRegister = addVar(propertyNames().arguments, false); // Can be changed by assigning to 'arguments'.
@@ -240 +240 @@
         
         if (shouldTearOffArgumentsEagerly()) {
-            emitOpcode(op_create_arguments);
-            instructions().append(argumentsRegister->index());
-        }
-
-        // The debugger currently retrieves the arguments object from an activation rather than pulling
-        // it from a call frame.  In the long-term it should stop doing that (<rdar://problem/6911886>),
-        // but for now we force eager creation of the arguments object when debugging.
-        if (m_shouldEmitDebugHooks) {
             emitOpcode(op_create_arguments);
             instructions().append(argumentsRegister->index());