Title: [137505] trunk/Source/_javascript_Core
- Revision
- 137505
- Author
- [email protected]
- Date
- 2012-12-12 13:11:41 -0800 (Wed, 12 Dec 2012)
Log Message
OSR exit compiler should emit code for resetting the execution counter that matches the logic of ExecutionCounter.cpp
https://bugs.webkit.org/show_bug.cgi?id=104791
Reviewed by Oliver Hunt.
The OSR exit compiler wants to make it so that every OSR exit does the equivalent
of:
codeBlock->m_jitExecuteCounter.setNewThreshold(
codeBlock->counterValueForOptimizeAfterLongWarmUp());
This logically involves:
- Resetting the counter to zero.
- Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
- Figuring out the scaled threshold, subtracting the count so far (which is zero,
so this part is a no-op), and clipping (ExecuteCounter::clippedThreshold()).
- Setting m_counter to the negated clipped threshold.
- Setting m_totalCount to the previous count so far (which is zero) plus the
clipped threshold.
Because of the reset, which sets the count-so-far to zero, this amounts to:
- Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
- Figuring out the clipped scaled threshold.
- Setting m_counter to the negated clipped scaled threshold.
- Setting m_totalCount to the (positive) clipped scaled threshold.
The code was previously not doing this, but now is. This is performance neutral.
The only change in behavior over what the code was previously doing (setting the
m_counter to the negated scaled threshold, without clipping, and then setting
the m_totalCount to the clipped scaled threshold) is that this will respond more
gracefully under memory pressure and will ensure that we get more value profile
LUBing before triggering recompilation. More LUBing is almost always a good
thing.
* dfg/DFGOSRExitCompiler.cpp:
(JSC::DFG::OSRExitCompiler::handleExitCounts):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (137504 => 137505)
--- trunk/Source/_javascript_Core/ChangeLog 2012-12-12 21:07:12 UTC (rev 137504)
+++ trunk/Source/_javascript_Core/ChangeLog 2012-12-12 21:11:41 UTC (rev 137505)
@@ -1,3 +1,44 @@
+2012-12-12 Filip Pizlo <[email protected]>
+
+ OSR exit compiler should emit code for resetting the execution counter that matches the logic of ExecutionCounter.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=104791
+
+ Reviewed by Oliver Hunt.
+
+ The OSR exit compiler wants to make it so that every OSR exit does the equivalent
+ of:
+
+ codeBlock->m_jitExecuteCounter.setNewThreshold(
+ codeBlock->counterValueForOptimizeAfterLongWarmUp());
+
+ This logically involves:
+
+ - Resetting the counter to zero.
+ - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
+ - Figuring out the scaled threshold, subtracting the count so far (which is zero,
+ so this part is a no-op), and clipping (ExecuteCounter::clippedThreshold()).
+ - Setting m_counter to the negated clipped threshold.
+ - Setting m_totalCount to the previous count so far (which is zero) plus the
+ clipped threshold.
+
+ Because of the reset, which sets the count-so-far to zero, this amounts to:
+
+ - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
+ - Figuring out the clipped scaled threshold.
+ - Setting m_counter to the negated clipped scaled threshold.
+ - Setting m_totalCount to the (positive) clipped scaled threshold.
+
+ The code was previously not doing this, but now is. This is performance neutral.
+ The only change in behavior over what the code was previously doing (setting the
+ m_counter to the negated scaled threshold, without clipping, and then setting
+ the m_totalCount to the clipped scaled threshold) is that this will respond more
+ gracefully under memory pressure and will ensure that we get more value profile
+ LUBing before triggering recompilation. More LUBing is almost always a good
+ thing.
+
+ * dfg/DFGOSRExitCompiler.cpp:
+ (JSC::DFG::OSRExitCompiler::handleExitCounts):
+
2012-12-12 Ilya Tikhonovsky <[email protected]>
Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo.
Modified: trunk/Source/_javascript_Core/dfg/DFGOSRExitCompiler.cpp (137504 => 137505)
--- trunk/Source/_javascript_Core/dfg/DFGOSRExitCompiler.cpp 2012-12-12 21:07:12 UTC (rev 137504)
+++ trunk/Source/_javascript_Core/dfg/DFGOSRExitCompiler.cpp 2012-12-12 21:11:41 UTC (rev 137505)
@@ -154,14 +154,15 @@
tooFewFails.link(&m_jit);
// Adjust the execution counter such that the target is to only optimize after a while.
- int32_t targetValue =
- ExecutionCounter::applyMemoryUsageHeuristicsAndConvertToInt(
- m_jit.baselineCodeBlock()->counterValueForOptimizeAfterLongWarmUp(),
- m_jit.baselineCodeBlock());
- m_jit.store32(AssemblyHelpers::TrustedImm32(-targetValue), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecuteCounter()));
- targetValue = ExecutionCounter::clippedThreshold(m_jit.codeBlock()->globalObject(), targetValue);
- m_jit.store32(AssemblyHelpers::TrustedImm32(targetValue), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecutionActiveThreshold()));
- m_jit.store32(AssemblyHelpers::TrustedImm32(ExecutionCounter::formattedTotalCount(targetValue)), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecutionTotalCount()));
+ int32_t activeThreshold =
+ m_jit.baselineCodeBlock()->counterValueForOptimizeAfterLongWarmUp();
+ int32_t targetValue = ExecutionCounter::applyMemoryUsageHeuristicsAndConvertToInt(
+ activeThreshold, m_jit.baselineCodeBlock());
+ int32_t clippedValue =
+ ExecutionCounter::clippedThreshold(m_jit.codeBlock()->globalObject(), targetValue);
+ m_jit.store32(AssemblyHelpers::TrustedImm32(-clippedValue), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecuteCounter()));
+ m_jit.store32(AssemblyHelpers::TrustedImm32(activeThreshold), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecutionActiveThreshold()));
+ m_jit.store32(AssemblyHelpers::TrustedImm32(ExecutionCounter::formattedTotalCount(clippedValue)), AssemblyHelpers::Address(GPRInfo::regT0, CodeBlock::offsetOfJITExecutionTotalCount()));
doneAdjusting.link(&m_jit);
}
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-changes