Changeset 154854 in webkit for trunk/Source/JavaScriptCore/dfg/DFGDriver.cpp

Timestamp:

Aug 29, 2013, 4:45:26 PM (12 years ago)

Author:

[email protected]

Message:

Teach DFG::Worklist and its clients that it may be reused for different kinds of compilations
​https://bugs.webkit.org/show_bug.cgi?id=120489

Reviewed by Geoffrey Garen.

If the baseline JIT hits an OSR entry trigger into the DFG and we already have a
DFG compilation but we've also started one or more FTL compilations, then we
shouldn't get confused. Previously we would have gotten confused because we would
see an in-process deferred compile (the FTL compile) and also an optimized
replacement (the DFG code).

If the baseline JIT hits an OSR entry trigger into the DFG and we previously
did two things in this order: triggered a tier-up compilation from the DFG into
the FTL, and then jettisoned the DFG code because it exited a bunch, then we
shouldn't be confused by the presence of an in-process deferred compile (the FTL
compile). Previously we would have waited for that compile to finish; but the more
sensible thing to do is to let it complete and then invalidate it, while at the
same time enqueueing a DFG compile to create a new, more valid, DFG code block.

If the DFG JIT hits a loop OSR entry trigger (into the FTL) and it has already
triggered an FTL compile for replacement, then it should fire off a second compile
instead of thinking that it can wait for that one to finish. Or vice-versa. We
need to allow for two FTL compiles to be enqueued at the same time (one for
replacement and one for OSR entry in a loop).

Then there's also the problem that DFG::compile() is almost certainly going to be
the hook for triggering both DFG compiles and the two kinds of FTL compiles, but
right now there is no way to tell it which one you want.

This fixes these problems and removes a bunch of potential confusion by making the
key for a compile in the DFG::Worklist be a CompilationMode (one of DFGMode,
FTLMode, or FTLForOSREntryMode). That mode is also passed to DFG::compile().

Awkwardly, this still leaves us in a no DFG->FTL tier-up situation - so
DFG::compile() is always passed DFGMode and then it might do an FTL compile if
possible. Fixing that is a bigger issue for a later changeset.

• CMakeLists.txt:
• GNUmakefile.list.am:
• JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
• JavaScriptCore.xcodeproj/project.pbxproj:
• Target.pri:
• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::checkIfOptimizationThresholdReached):

• dfg/DFGCompilationKey.cpp: Added.

(JSC::DFG::CompilationKey::dump):

• dfg/DFGCompilationKey.h: Added.

(JSC::DFG::CompilationKey::CompilationKey):
(JSC::DFG::CompilationKey::operator!):
(JSC::DFG::CompilationKey::isHashTableDeletedValue):
(JSC::DFG::CompilationKey::profiledBlock):
(JSC::DFG::CompilationKey::mode):
(JSC::DFG::CompilationKey::operator==):
(JSC::DFG::CompilationKey::hash):
(JSC::DFG::CompilationKeyHash::hash):
(JSC::DFG::CompilationKeyHash::equal):

• dfg/DFGCompilationMode.cpp: Added.

(WTF::printInternal):

• dfg/DFGCompilationMode.h: Added.
• dfg/DFGDriver.cpp:

(JSC::DFG::compileImpl):
(JSC::DFG::compile):

• dfg/DFGDriver.h:
• dfg/DFGPlan.cpp:

(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::key):

• dfg/DFGPlan.h:
• dfg/DFGWorklist.cpp:

(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::runThread):

• dfg/DFGWorklist.h:
• jit/JITStubs.cpp:

(JSC::DEFINE_STUB_FUNCTION):

File:

• trunk/Source/JavaScriptCore/dfg/DFGDriver.cpp (modified) (4 diffs)

trunk/Source/JavaScriptCore/dfg/DFGDriver.cpp

@@ -55 +55 @@
 
 #if ENABLE(DFG_JIT)
-static CompilationResult compileImpl(ExecState* exec, CodeBlock* codeBlock, unsigned osrEntryBytecodeIndex, PassRefPtr<DeferredCompilationCallback> callback, Worklist* worklist)
+static CompilationResult compileImpl(
+    ExecState* exec, CodeBlock* codeBlock, CompilationMode mode,
+    unsigned osrEntryBytecodeIndex, PassRefPtr<DeferredCompilationCallback> callback,
+    Worklist* worklist)
 {
     SamplingRegion samplingRegion("DFG Compilation (Driver)");
@@ -99 +102 @@
         numVarsWithValues = 0;
     RefPtr<Plan> plan = adoptRef(
-        new Plan(codeBlock, osrEntryBytecodeIndex, numVarsWithValues));
+        new Plan(codeBlock, mode, osrEntryBytecodeIndex, numVarsWithValues));
     for (size_t i = 0; i < plan->mustHandleValues.size(); ++i) {
         int operand = plan->mustHandleValues.operandForIndex(i);
@@ -127 +130 @@
 }
 #else // ENABLE(DFG_JIT)
-static CompilationResult compileImpl(ExecState*, CodeBlock*, unsigned, PassRefPtr<DeferredCompilationCallback>, Worklist*)
+static CompilationResult compileImpl(
+    ExecState*, CodeBlock*, CompilationMode, unsigned,
+    PassRefPtr<DeferredCompilationCallback>, Worklist*)
 {
     return CompilationFailed;
@@ -133 +138 @@
 #endif // ENABLE(DFG_JIT)
 
-CompilationResult compile(ExecState* exec, CodeBlock* codeBlock, unsigned osrEntryBytecodeIndex, PassRefPtr<DeferredCompilationCallback> passedCallback, Worklist* worklist)
+CompilationResult compile(
+    ExecState* exec, CodeBlock* codeBlock, CompilationMode mode,
+    unsigned osrEntryBytecodeIndex, PassRefPtr<DeferredCompilationCallback> passedCallback,
+    Worklist* worklist)
 {
     RefPtr<DeferredCompilationCallback> callback = passedCallback;
-    CompilationResult result = compileImpl(exec, codeBlock, osrEntryBytecodeIndex, callback, worklist);
+    CompilationResult result = compileImpl(
+        exec, codeBlock, mode, osrEntryBytecodeIndex, callback, worklist);
     if (result != CompilationDeferred)
         callback->compilationDidComplete(codeBlock, result);