Dynamic Languages need Dynamic Compilers Maxime Chevalier-Boisvert - - PowerPoint PPT Presentation
Dynamic Languages need Dynamic Compilers Maxime Chevalier-Boisvert mloc.js 2014 Introduction PhD candidate at the Universit de Montral, prof. Marc Feeley Research: compilers, optimizing dynamic languages, JS This talk is about:
2
– Dynamic languages – JIT compilation & optimization – The Higgs JS compiler – Basic block versioning – Lazy incremental compilation
3
– Originally ran in an interpreter, back in 1995 – Today, all browsers have JIT compilers
– e.g.: JS, Python, Ruby, PHP, Perl, MATLAB, LISPs
– Rapid prototyping, short development cycles
4
– Variables can change type over time – Types associated with values – No type annotations
– Symbols resolved dynamically (e.g.: globals) – Dynamic loading of code (eval, load)
– Dynamic arrays – Objects as dictionaries/maps
5
6
– Write less code for the same result – Each line of code conveys more meaning
– Invisible work happen behind the scenes – This invisible work carries extra overhead
7
– Different operations for different inputs
– Integer addition – Floating-point addition – String concatenation – Array appending
– Functions with cascades of if statements testing types
8
9
11
– Observe, monitor programs as they run – Modify code at run time
– Code adapted to program's behavior – Don't account for unexecuted code
– Compiler books are all about AOT compilers
12
– Open source, mostly written in D – Self-hosted runtime library, in JS – Relatively small codebase (~ 50 KLOC)
– No with statement, no getters/setters – Extras: Foreign Function Interface (FFI)
– Try new ideas, uncharted territory – Basic block versioning, lazy incremental compilation
13
– Exposes low-level operations (e.g.: machine integer ops)
– Avoids opaque calls into C or D code
– e.g.: type information – Branch tests add type & shape information
– Type information: type tags, variables, objects – Potentially: register allocation state
15
A C B D false true
16
is_int32(n)? C B D false true
17
18
is_int32(n)? C B D false true
19
is_int32(n)? C B D false true n is int32
20
is_int32(n)? C B D false true n is not int32 n is int32
21
is_int32(n)? C B D false true n is not int32 n is int32 n is ???
22
is_int32(n)? C B D' false true n is not int32 n is int32 D'' n is int32 n is not int32
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
– Fixed-point on types – Types found must agree with all inputs – Pessimistic, conservative answer
– Multiple solutions possible for each block – Don't necessarily have to sacrifice – Fixed-point on versioning of blocks
43
– Constant propagation – Granularity of type info used – How much is too much?
44
45
46
47
48
– Can place hard upper limit on compilation time – Not worried about time/code size blowup
49
– Method-based JIT: not enough information – Can't know which paths will/won't be executed
– Primitives are relatively large functions – Inlining large functions is slow, inefficient – On short benchmarks, inlining doesn't pay for itself
50
– V8, SpiderMonkey, JSC, Java VMs – Functions as a compilation unit
– Often done lazily, on first call
– Info available at compilation time may be limited – If changing compiled code, recompile whole method – Inlining requires recompilation
51
– Small chunk of code with no control-flow inside – e.g.: then clause of if statement, body of a loop
– Compiles blocks lazily: when they are first executed
– e.g.: never executed error handling is never compiled
52
53
54
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
55
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
56
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
57
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
58
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
59
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
60
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
61
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
62
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
63
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
64
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
65
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
66
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
67
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(3) print(x)
68
typeof v === 'number' foo(v) return v typeof v === 'string' return v.length
x = foo(i) print(x)
69
– Each JS operator is a costly function call
– Copying, transforming IR nodes – Recompiling entire methods to inline callees
– High cost of recompiling/replacing caller function – Eliminate call overhead, inlined code may be faster
– Inline a huge function, only use a small part of it
70
– Incrementally compile callee as if part of caller – Patch call site, jump to the inlined function
– Avoid throwing away compiled code – Do away with on-stack replacement – Inline only what is executed in the callee
71
– Tested on ~30 JS benchmarks – Bug reports & pull requests welcome
– Results to be published soon
72
– Small codebase, highly commented, helpful people
– Parser, AST, IR, x86 codegen, runtime, stdlib
– Tinker with it, new primitivies, extend the language
– C FFI: malloc/free, fork, stdio, etc. – Low-level machine instructions
73
74