Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Improving JavaScript Performance Through Predic...

Improving JavaScript Performance Through Predictable Type Specialization

A paper about improving modern JIT-compilers. Presented by Liang Gong in Berkeley's group meeting.

Liang Gong

April 01, 2017
Tweet

More Decks by Liang Gong

Other Decks in Research

Transcript

  1. 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
  2. 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
  3. 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.
  4. 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
  5. 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
  6. 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.
  7. __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?
  8. 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
  9. Changing the prototype -> creating a new hidden class How

    to remedy? Solution: Decouple Prototypes From Types (hidden classes)
  10. … 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?
  11. 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
  12. A new method binding  a new hidden class V8

    gives up method binding in hidden when function bindings are changed But still, type unpredictable…
  13. Changing method binding -> creating a new hidden class How

    to remedy? Solution: Decouple Function Property Bindings From Types (hidden classes)
  14. 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:
  15. B: baseline (original V8) B*: B disable flush IC across

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

    page loads P: B* enhanced with Prototype decoupling C: B* with both proposed enhancements
  17. 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
  18. 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