It seems that a well-intentioned no-DFG-JIT build fix borked it.
Created attachment 168573 [details] the patch
Landed in http://trac.webkit.org/changeset/131268
Comment on attachment 168573 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=168573&action=review > Source/JavaScriptCore/ChangeLog:11 > + canBeOptimized() returns true. But m_canBeOptimized is only initialized during > + full method compiles, so in a stub compile it may (or may not) be false, meaning Please also fix the JIT constructor, so that it default-initializes m_canBeOptimized to false. Why is this initialization code in privateCompile(), and not in the the constructor, to begin with?
(In reply to comment #3) > (From update of attachment 168573 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=168573&action=review > > > Source/JavaScriptCore/ChangeLog:11 > > + canBeOptimized() returns true. But m_canBeOptimized is only initialized during > > + full method compiles, so in a stub compile it may (or may not) be false, meaning > > Please also fix the JIT constructor, so that it default-initializes m_canBeOptimized to false. https://bugs.webkit.org/show_bug.cgi?id=99283 > > Why is this initialization code in privateCompile(), and not in the the constructor, to begin with? I think that it makes sense for the decision logic to be in privateCompile(). In particular, this statement: DFG::CapabilityLevel level = m_codeBlock->canCompileWithDFG(); does an O(n) walk over the code block's bytecode. We don't want that to happen every time we construct a JIT, since we do that for every stub compile.