Bug 117906 – fourthTier: DFG shouldn't exit just because a String GetByVal went out-of-bounds

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Filip Pizlo]

Patch forthcoming.

[Filip Pizlo]

Created attachment 205235 [details]
work in progress

[Filip Pizlo]

Created attachment 205237 [details]
the ptach

Benchmark report for JSRegress on dethklok (MacBookPro9,1).

VMs tested:
"TipOfTree" at /Volumes/Data/pizlo/fourthTier/secondary/OpenSource/WebKitBuild/Release/jsc (r151875)
"FixString" at /Volumes/Data/pizlo/fourthTier/primary/OpenSource/WebKitBuild/Release/jsc (r151873)

Collected 30 samples per benchmark/VM, with 10 VM invocations per benchmark. Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to
get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds.

                                                TipOfTree                 FixString                                     

string-get-by-val-big-char                    8.6687+-0.3165            8.4542+-0.2872          might be 1.0254x faster
string-get-by-val-out-of-bounds-insane        7.2589+-0.3855     ^      5.9114+-0.2240        ^ definitely 1.2280x faster
string-get-by-val-out-of-bounds              54.9499+-0.7410     ^      2.5956+-0.0318        ^ definitely 21.1704x faster
string-get-by-val                             2.3552+-0.1035            2.3321+-0.0938        

<arithmetic>                                 18.3082+-0.2274     ^      4.8233+-0.0892        ^ definitely 3.7958x faster
<geometric> *                                 9.4639+-0.1531     ^      4.1602+-0.0602        ^ definitely 2.2749x faster
<harmonic>                                    5.7086+-0.1329     ^      3.6167+-0.0511        ^ definitely 1.5784x faster

[Mark Hahnenberg]

Comment on attachment 205237 [details]
the ptach

View in context: https://bugs.webkit.org/attachment.cgi?id=205237&action=review

r=me

> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:2060
> +            m_jit.addLazily(

Just for my education, what does addLazily do/what is its purpose?

> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:2100
> +    

:-(

[Filip Pizlo]

(In reply to comment #3)
> (From update of attachment 205237 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205237&action=review
> 
> r=me
> 
> > Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:2060
> > +            m_jit.addLazily(
> 
> Just for my education, what does addLazily do/what is its purpose?

You can't add to a watchpoint set during DFG compilation anymore, since DFG compilation is concurrent.  So you just register your intent to be added.

Then when the main thread installs the code, it checks that the desired watchpoints are still valid; if they aren't then the compilation is discarded and if they are then the watchpoints are installed.

> 
> > Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:2100
> > +    
> 
> :-(

[Mark Hahnenberg]

> 
> You can't add to a watchpoint set during DFG compilation anymore, since DFG compilation is concurrent.  So you just register your intent to be added.
> 
> Then when the main thread installs the code, it checks that the desired watchpoints are still valid; if they aren't then the compilation is discarded and if they are then the watchpoints are installed.

Cool, that's what I thought.

[Filip Pizlo]

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