Bug 99258 – Array length array profiling is broken in the baseline JIT

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Filip Pizlo]

It seems that a well-intentioned no-DFG-JIT build fix borked it.

[Filip Pizlo]

Created attachment 168573 [details]
the patch

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/131268

[Geoffrey Garen]

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?

[Filip Pizlo]

(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.