CallLinkStatus should return takesSlowPath if the GC often cleared the IC
https://bugs.webkit.org/show_bug.cgi?id=145502
Reviewed by Geoffrey Garen.
CallLinkInfo now remembers when it has been cleared by GC. This has some safeguards for when
a call gets cleared by GC only because we hadn't converted it into a closure call; in that
case the GC will just tell us that it should be a closure call. The DFG will not optimize
a call that was cleared by GC, and the DFG will always prefer a closure call if the GC told
us that the specific callee was dead but the executable wasn't.
This guards us from some scenarios that came up in Speedometer. It's neutral on the pure JS
benchmarks, most likely just because those benchmarks aren't real enough to have interesting
GC of code.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::visitWeak):
(JSC::CallLinkInfo::dummy):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromCallLinkInfo):
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@185161 268f45cc-cd09-0410-ab3c-d52691b4dbfc
diff --git a/Source/JavaScriptCore/bytecode/CallLinkStatus.cpp b/Source/JavaScriptCore/bytecode/CallLinkStatus.cpp
index 911a806..815ee657 100644
--- a/Source/JavaScriptCore/bytecode/CallLinkStatus.cpp
+++ b/Source/JavaScriptCore/bytecode/CallLinkStatus.cpp
@@ -135,6 +135,9 @@
CallLinkStatus CallLinkStatus::computeFromCallLinkInfo(
const ConcurrentJITLocker&, CallLinkInfo& callLinkInfo)
{
+ if (callLinkInfo.clearedByGC)
+ return takesSlowPath();
+
// Note that despite requiring that the locker is held, this code is racy with respect
// to the CallLinkInfo: it may get cleared while this code runs! This is because
// CallLinkInfo::unlink() may be called from a different CodeBlock than the one that owns
@@ -148,11 +151,6 @@
// that is still marginally valid (i.e. the pointers ain't stale). This kind of raciness
// is probably OK for now.
- // FIXME: If the GC often clears this call, we should probably treat it like it always takes the
- // slow path. We could be smart about this; for example if we cleared a specific callee but the
- // despecified executable was alive then we could note that separately.
- // https://bugs.webkit.org/show_bug.cgi?id=145502
-
// PolymorphicCallStubRoutine is a GCAwareJITStubRoutine, so if non-null, it will stay alive
// until next GC even if the CallLinkInfo is concurrently cleared. Also, the variants list is
// never mutated after the PolymorphicCallStubRoutine is instantiated. We have some conservative
