University of Michigan Electrical Engineering and Computer Science Dynamic Parallelization of JavaScript Applications Using an Ultra-lightweight Speculation Mechanism Mojtaba Mehrara Po-Chun Hsu Mehrzad Samadi Scott Mahlke Advanced Computer Architecture Laboratory University of Michigan

Electrical Engineering and Computer Science Web 2.0 is Here More computation is moved to client-side –More responsive browsing –Avoid unnecessary network traffic 2 JavaScript + DHTML Client-side computation Server-side computation Client-side rendering Static HTML Web 1.0 Web 2.0 [Vikram et al., CCS’09]

University of Michigan Electrical Engineering and Computer Science Client-side Computation in JavaScript Flexibility, ease of prototyping, and portability 3 Poor performance is one of the main challenges

University of Michigan Electrical Engineering and Computer Science Client-side Applications 4 Interaction-intensive: –Largely composed of event handlers, triggered by user –Examples are Gmail, Facebook, etc. Compute-intensive: –Dominated by loops and hot functions –Online image editing such as Adobe’s Photoshop.com, Google’s Picnik –Lot more potential: Online games Video editing Sound editing and voice recognition

University of Michigan Electrical Engineering and Computer Science Improving JavaScript Performance Many efforts underway by browser developers to improve JavaScript sequential performance Hits a performance wall as multi-cores are becoming dominant Parallelism must be exploited to make use of multi-core clients JavaScript is inherently sequential Language and run-time system provide little/no concurrency support 5 Our proposal: Low-cost dynamic & speculative parallelization of JavaScript applications Our proposal: Low-cost dynamic & speculative parallelization of JavaScript applications

University of Michigan Electrical Engineering and Computer Science JavaScript Parallelization A typical static parallelization flow 6 Source code Memory dependence analysis Parallel code generation Parallel execution Compile time Runtime Memory profiling Data flow analysis Runtime Dynamic parallelization $ $ Speculation engine (Software transactional memory) $

University of Michigan Electrical Engineering and Computer Science Our Approach: ParaScript Light-weight dynamic analysis & code generation for speculative DOALL loops Low-cost customized SW speculation with a single checkpoint 7 Hot loop detection Initial parallelizability assessment Parallel Code generation Parallel execution Sequential execution Loop Selection Runtime Customized speculation Finish Abort

University of Michigan Electrical Engineering and Computer Science Dependence Analysis 8 JIT compilation time data flow analysis Runtime initial tests + range-based monitoring Runtime reference-counting-based monitoring

University of Michigan Electrical Engineering and Computer Science Scalar Array Conflict Detection Initial assessment catches trivial conflicts Keep track of max and min accessed element indices Cross-check RD/WR sets after thread execution 9 A[0] = … A[5] = … B[7] = … A[6] = A[5]+1 Thread 1 Thread 2 &A05 Array write-set &A66 Array write-set &B77 &A55 Array read-set ptr min max

University of Michigan Electrical Engineering and Computer Science Object Array Conflict Detection More involved than scalar arrays Different indices of the same array may point to the same object 10 ptr RefCnt myObj0 header ptr RefCnt myObj1 header A &A 1 1 B &B 1 2 If dependent based on data-flow analysis If dependent based on data-flow analysis

University of Michigan Electrical Engineering and Computer Science Loop Selection Focus on DOALL-counted (e.g. for loops) Avoid parallelizing loops with: –Browser interactions –HTTP request functions –Runtime code insertion 11 var addFunction = new Function("a", "b“, "return a+b;"); Function addFunction(a, b){ return a+b; } eval("a = 7; b = 13; document.write(a+b);"); a = 7; b = 13; document.write(a+b); Requires locks on browser internals Requires locks on browser internals Requires server-side speculation Requires server-side speculation

University of Michigan Electrical Engineering and Computer Science Checkpointing Mechanism Go through all references, clone them, and ask GC not to touch the clones 12 Cloning process Strings, numbers and Booleans Copy the values Custom objects Deep-copy all properties, avoid recursion Functions - Same as custom objects - No need to clone source code Arrays Clone all properties and elements Monitor overhead, back out if more expensive than a threshold

University of Michigan Electrical Engineering and Computer Science Checkpointing Optimizations Selective variable cloning –Only clone a variable if it is touched during speculative execution Array clone elimination –Large arrays holding results of browser functions –Instead of cloning the array, just call the function again for recovery E.g. getImageData in the canvas HTML5 element 13

University of Michigan Electrical Engineering and Computer Science Parallel Code Generation 14 IE = min(IS+CS*SS,n); for (i=IS;i<IE;i+=SS) // original loop code for (i=IS;i<IE;i+=SS) // original loop code conflictcheck(); chunkbarrier() IS+=CS * TC * SS; conflictcheck(); chunkbarrier() IS+=CS * TC * SS; Parallel Loop Loop Barrier Reduction variable & conditional live-out aggregation -Take checkpoint -Spawn threads

University of Michigan Electrical Engineering and Computer Science Experimental Setup Implemented in Firefox 3.7a1pre Subset of SunSpider benchmark suite –Others identified as not parallelizable early on, causing 2% slow-down due to the initial analysis. A set of Pixastic Image Processing filters 8-processor system -- 2 Intel Xeon Quad-cores, running Ubuntu 9.10 Ran each benchmark 10 times and took the average 15

University of Michigan Electrical Engineering and Computer Science Parallelism Coverage 16 High fraction of sequential execution in the getImageData() browser function DOALL loop that extracts pixel RGB & alpha values High fraction of sequential execution in the getImageData() browser function DOALL loop that extracts pixel RGB & alpha values

University of Michigan Electrical Engineering and Computer Science SunSpider 17 A long iteration dominates execution

University of Michigan Electrical Engineering and Computer Science Pixastic Image Processing 18 2 threads 4 threads 8 threads 1 thread High memory op to computation ratio

University of Michigan Electrical Engineering and Computer Science Conclusion Web applications dominance is pushing JavaScript to the forefront of computing Dynamic environment and performance constraints makes parallelization challenging We introduce efficient solutions for exploiting parallelism 17% speculation overhead across all benchmarks ParaScript achieved an average of 2.55x and 1.82x speedup on 8 processors for SunSpider and Pixastic 19

University of Michigan Electrical Engineering and Computer Science Thank You! Questions? 20