Improving JavaScript Performance Through Predictable Type Specialization To appear in PLDI 2014 Wonsun Ahn, Jiho Choi, Thomas Shull, Maria Garzaran, Josep Torrellas Slides made and presented by Liang Gong in Correctness Group Meeting @ UC Berkeley 

Improve JavaScript Performance Through Predictable Type Specialization Story line is simple: (1) Identify two bad design decisions in JIT-compiler (leads to bad performance) (2) Remove those limitations by enhance those designs (3) Evaluation shows performance improvements on real-world websites 

Improve JavaScript Performance Through Predictable Type Specialization Two bad decisions in JIT-compiler that leads to low performance: (1)The inherited prototype object is part of the object’s type definition (2)The method binding is part of the type definition types unpredictable --> Hard to perform type specialization --> hard to do optimization Previously most browsers were focusing on getting speed up on benchmarks rather than real-world websites. 

Hidden Class p2 

Inline Cache An inline cache miss An inline cache hit An inline cache hit requires 3-60 instructions, while an inline cache miss requires between 1000 ~ 4000 instructions 

Existing JIT optimization works well for benchmarks, but not effective for real-world websites Baseline: when all the v8 optimization applied No Crankshaft: No inlining, no global value numbering etc. No Crankshaft, No IC: No Crankshaft with inline caching disabled 

Identify 2 designs in JIT-compiler that leads to low performance: (1)The inherited prototype object is part of the object’s type definition (2)The method binding should also be part of the type definition Makes types very unpredictable Hard for the compiler to perform type specialization Previously most browsers were focusing on getting speed up on benchmarks rather than real-world websites. 

__proto__ field in the hidden is immutable … Bad Decision: (1)The inherited prototype object is part of the object’s type definition Second Culprit: Method Bindings Drawback: Changing the prototype -> creating a new hidden class Binding prototype with hidden class, makes looking up properties in prototype chains easier Why is this a problem? 

Changing the prototype -> creating a new hidden class Why is this a problem? Observation: (1) No. of properties will saturate after several rounds of execution (2) But changes to prototypes seems to happen all the time ==> hidden classes are created all the time 

A new constructor in each iteration  a new prototype object 

Changing the prototype -> creating a new hidden class How to remedy? Solution: Decouple Prototypes From Types (hidden classes) 

… Bad Decision: (2) Put method binding into the hidden class Second Culprit: Prototypes … … Reasonable Design, as most OO languages do Foo and bar are immutable When hidden class are known, method bindings are known Drawback: Changing method binding -> creating a new hidden class Why is this a problem? 

Changing method binding -> creating a new hidden class Why is this a problem? Observation: (1) Frequent changes in method bindings  excessive hidden class  type unpredictability 

A new method binding  a new hidden class V8 gives up method binding in hidden when function bindings are changed But still, type unpredictable… 

Lots of inline cache misses 

Changing method binding -> creating a new hidden class How to remedy? Solution: Decouple Function Property Bindings From Types (hidden classes) 

New design advantages: (1) types are predictable  increased type-hit-rate (2) types are predictable  enable V8 optimizations that depends on type stability New design disadvantages: (1) prototypes and method bindings cannot be hard coded  needs to be loaded on the fly  slight delay New design advantages: (1) decreases number of hidden classes New design disadvantages: (1) prototype field moved from hidden class to objects  increased memory usage On Performance: On Memory: 

Lots of time are wasted on runtime code after Inline Cache misses 

B: baseline (original V8) B*: B disable flush IC across page loads P: B* enhanced with Prototype decoupling C: B* with both proposed enhancements 

B: baseline (original V8) B*: B disable flush IC across page loads P: B* enhanced with Prototype decoupling C: B* with both proposed enhancements 

B: baseline (original V8) B*: B disable flush IC across page loads P: B* enhanced with Prototype decoupling C: B* with both proposed enhancements Heap Usage in KB No report on Memory Usage of benchmarks XD 

Observation is not supported by any evidence: Evaluation weakness (1) uses JSBench -> amazon, google, yahoo, and facebook. Why not running V8 on top 100 websites and interact with it lively? JSBench is a series of statements recorded, improvement might be over fitting (2) No report on memory usage on benchmark. Since no flush of inline cache, what would happen if browsing many different Websites, probably run out of memory. Counter examples are very inefficient that are less likely to happen everywhere. The paper does not report how often this kind of inefficient code patterns are executed 

Thank you!