Dynamic Parallelization of JavaScript Applications

assoverwroughtΤεχνίτη Νοημοσύνη και Ρομποτική

6 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

71 εμφανίσεις

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

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

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

Variable

category

Analysis and runtime

speculation method

Scalars

&
Objects

Scalar arrays

Object arrays

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

&A

0

5

Array write
-
set

&A

6

6

Array write
-
set

&B

7

7

&A

5

5

Array
read
-
set


ptr

min max


ptr

min max


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

&A

1

1

B

&B

1

2

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

Source code

Runtime

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

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

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

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