Title: [183691] trunk/Source/_javascript_Core
- Revision
- 183691
- Author
- [email protected]
- Date
- 2015-05-01 15:33:32 -0700 (Fri, 01 May 2015)
Log Message
Function allocation sinking shouldn't be performed on singleton functions
https://bugs.webkit.org/show_bug.cgi?id=144166
Reviewed by Geoffrey Garen.
Function allocations usually are free of any other side effects, but
this is not the case for allocations performed while the underlying
FunctionExecutable is still a singleton (as this allogation will fire
watchpoints invalidating code that depends on it being a singleton).
As the object allocation sinking phase assumes object allocation is
free of side-effects, sinking these allocations is not correct.
This also means that when materializing a function allocation on OSR
exit, that function's executable will never be a singleton, and we don't have
to worry about its watchpoint, allowing us to use
JSFunction::createWithInvalidatedRellocationWatchpoint instead of
JSFunction::create.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (183690 => 183691)
--- trunk/Source/_javascript_Core/ChangeLog 2015-05-01 21:18:05 UTC (rev 183690)
+++ trunk/Source/_javascript_Core/ChangeLog 2015-05-01 22:33:32 UTC (rev 183691)
@@ -1,3 +1,28 @@
+2015-05-01 Basile Clement <[email protected]>
+
+ Function allocation sinking shouldn't be performed on singleton functions
+ https://bugs.webkit.org/show_bug.cgi?id=144166
+
+ Reviewed by Geoffrey Garen.
+
+ Function allocations usually are free of any other side effects, but
+ this is not the case for allocations performed while the underlying
+ FunctionExecutable is still a singleton (as this allogation will fire
+ watchpoints invalidating code that depends on it being a singleton).
+ As the object allocation sinking phase assumes object allocation is
+ free of side-effects, sinking these allocations is not correct.
+
+ This also means that when materializing a function allocation on OSR
+ exit, that function's executable will never be a singleton, and we don't have
+ to worry about its watchpoint, allowing us to use
+ JSFunction::createWithInvalidatedRellocationWatchpoint instead of
+ JSFunction::create.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+
2015-04-30 Jon Davis <[email protected]>
Web Inspector: console should show an icon for console.info() messages
Modified: trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp (183690 => 183691)
--- trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp 2015-05-01 21:18:05 UTC (rev 183690)
+++ trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp 2015-05-01 22:33:32 UTC (rev 183691)
@@ -786,7 +786,8 @@
break;
case NewFunction:
- sinkCandidate();
+ if (!node->castOperand<FunctionExecutable*>()->singletonFunction()->isStillValid())
+ sinkCandidate();
m_graph.doToChildren(
node,
[&] (Edge edge) {
Modified: trunk/Source/_javascript_Core/ftl/FTLOperations.cpp (183690 => 183691)
--- trunk/Source/_javascript_Core/ftl/FTLOperations.cpp 2015-05-01 21:18:05 UTC (rev 183690)
+++ trunk/Source/_javascript_Core/ftl/FTLOperations.cpp 2015-05-01 22:33:32 UTC (rev 183691)
@@ -106,7 +106,7 @@
}
RELEASE_ASSERT(executable && activation);
- JSFunction* result = JSFunction::create(vm, executable, activation);
+ JSFunction* result = JSFunction::createWithInvalidatedReallocationWatchpoint(vm, executable, activation);
return result;
}
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
