Changeset 153243 in webkit for trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp

Timestamp:

Jul 24, 2013, 9:03:36 PM (12 years ago)

Author:

[email protected]

Message:

fourthTier: GC's put_by_id transition fixpoint should converge more quickly
​https://bugs.webkit.org/show_bug.cgi?id=117912

Reviewed by Mark Hahnenberg.

This was a rookie mistake. The GC does a classic forward data flow fixpoint. These work well so long as you
iterate the program in program order, or at least something close to program order. Because I enjoy reverse
loops ("while (n--) blah"), I ended up iterating in *reverse* of program order which ensured worst-case
pathologies every single time. And unsurprisingly, this slowed down a program, namely pdfjs.

Flipping the loops to iterate forward fixes a 90% regression in Octane/pdfjs and is otherwise neutral.

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::propagateTransitions):

File:

• trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp (modified) (2 diffs)

trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp

@@ -1973 +1973 @@
     if (jitType() == JITCode::InterpreterThunk) {
         const Vector<unsigned>& propertyAccessInstructions = m_unlinkedCode->propertyAccessInstructions();
-        for (size_t i = propertyAccessInstructions.size(); i--;) {
+        for (size_t i = 0; i < propertyAccessInstructions.size(); ++i) {
             Instruction* instruction = &instructions()[propertyAccessInstructions[i]];
             switch (interpreter->getOpcodeID(instruction[0].u.opcode)) {
@@ -1995 +1995 @@
 #if ENABLE(JIT)
     if (JITCode::isJIT(jitType())) {
-        for (unsigned i = m_structureStubInfos.size(); i--;) {
+        for (unsigned i = 0; i < m_structureStubInfos.size(); ++i) {
             StructureStubInfo& stubInfo = m_structureStubInfos[i];
             switch (stubInfo.accessType) {