Slide 1

Slide 1 text

How Javascript Works?

Slide 2

Slide 2 text

Name !CSO ੨໺݈ར Occupation 'SPOUFOE%FWFMPQFS1SPEVDU0XOFS Company $ZCFSBHFOUΞυςΫελδΦ"*.FTTFOHFS OSS $POUSJCVUPSPG7 About IUUQJOGPCODI

Slide 3

Slide 3 text

Where we work on?

Slide 4

Slide 4 text

Javascript Ruby Java Machine Language Assembler C/C++ Rust Go English Japanese etc… “High-level” “Low-level”

Slide 5

Slide 5 text

Low-level language Low-level language mean “More hardware side” language. That mean we can control hardware behavior directly through programing languages. Low-level language has below pros & cons. • Pros) Very fast. Because Low-level language manipulate hardware directly. • Pros) Fun:) • Cons) Very dangerous. Because Low-level language has a least safety system. • Cons) Hard to write. Because Low-level language hasn’t any modern programing language features in many case.

Slide 6

Slide 6 text

High-level language High-level language mean “More human side” language. That mean we can control hardware behavior indirectly through more human readable and understandable language. High-level language has below pros & cons • Pros) Human readable and easy to write. (Becuase High-level language has intermediate translator that translate from High-level to Low-level) • Pros) High productivity. Because we are’t need to think many hardwares. • Cons) Slower than Low-level in many case.

Slide 7

Slide 7 text

Why we create High-level lang? Because Low-level language is very dangerous and difficult to cover many platforms. Programing history is efficient hardware - especially CPU - control history. But today, we have many CPU, so we can’t cover all CPU except a few people. And Low-level languages requires very complicated memory management and sometimes that cause memory leak which may difficult to solve and other dangerous bugs like buffer overflow. So to solve these problems, we have created some High-level programing languages.

Slide 8

Slide 8 text

Javascript Javascript is High-level programing language that created by Brendan Eich. That work on mainly browser or server(Node.js). This language has relatively many engines, compared to the other programing languages. E.g, V8(Google), JavascriptCore(WebKIT), SpiderMonkey(Mozilla) Today I will describe major 3 javascript engines.

Slide 9

Slide 9 text

Execution Steps

Slide 10

Slide 10 text

Lifecycle of javascript “Sourcecode” “Abstract Syntax Tree” “Bytecode” “Binary”

Slide 11

Slide 11 text

Parsing

Slide 12

Slide 12 text

AbstractSyntaxTree if (flag) { x = 100; } *G $POEJUJPO 5IFO (flag) 4UBUFNFOU "TTJHONFOU&YQSFTTJPO 7BS1SPYZ -JUFSBM x 100 “Parsing”

Slide 13

Slide 13 text

Parsing First, javascript engine load source codes and convert it to Abstract Syntax Tree. Parsing is conversion which convert from flatten source code strings to structured model.

Slide 14

Slide 14 text

Parser Generator Many languages are using ParserGenerrator like yacc. But almost javascript engines aren’t using ParserGenerator. They are mainly using Handwritten-Recursive-Descent-Parser. By using Handwritten-Recursive-Descent-Parser, engines can controll parsing process more flexibly.

Slide 15

Slide 15 text

Efficient Parsing Many javascript engines has no any wasted time, so they want to parse only needed, they are not want to parse waste source codes. How to solve this issue? V8 solve this issues by using PreParser which parse only source code layout, which mean all function bodies will skip.

Slide 16

Slide 16 text

PreParsing function someProcess(a, b, c) { ... } PreParsed Function information name : “someProcess” parameter-count : 3 start-position : 1 end-position : 34 use-super-property: false

Slide 17

Slide 17 text

Problematic grammars Javascript has curious grammars. If you start writing parser of javascript, you'll see ECMA262 grammars and you’ll find Cover* grammars. CoverParenthesizedExpressionAndArrowParameterList This long name grammar was created for arrow function and parenthesized expression like below. (a, b, c) => {...} (a, b, c); Arrow function and parenthesized expression can’t distinct until find “=>” glyph. So ecma262 solve this problem by treat this two grammar as same grammar tree that has different meaning.

Slide 18

Slide 18 text

Bytecode

Slide 19

Slide 19 text

Bytecode Bytecode is relatively low-level operation for VirtualMachine but bytecode is not machine language. It’s defined by each javascript engine.

Slide 20

Slide 20 text

Bytecode JumpIfToBooleanFalse LdaSmi StaGlobal Star r0 Ldar r0 0x260a7c81db19: [FixedArray] in OldSpace - map: 0x260aee2807a9 - length: 2 0: 0x260a7c81da59 1: 0x260a7c81da71 *G $POEJUJPO 5IFO (flag) 4UBUFNFOU "TTJHONFOU&YQSFTTJPO 7BS1SPYZ -JUFSBM x 100

Slide 21

Slide 21 text

Bytecode generation Almost all javascript engines are generating bytecode from AbstractSyntaxTree.

Slide 22

Slide 22 text

Interpreter

Slide 23

Slide 23 text

Interpreter Interpreter is a execution engine, but not execute machine language, generally, interpreter execute AST directly or execute bytecode. Today, almost all javascript engines has executing bytecode, so it’s called Bytecode Interpreter.

Slide 24

Slide 24 text

Optimizations

Slide 25

Slide 25 text

Pipelines V8 Javascript Core SpiderMonkey Ignition (Interpreter + Baseline JIT) JIT Optimization (TurboFan) Deoptimization Interpreter Simple JIT Optimization Deoptimization Full JIT Interpreter (LL Int) Baseline JIT Optimization Deoptimization DFG JIT FTL JIT

Slide 26

Slide 26 text

Pipelines Alomost all current javascript engines has implemented pipeline below. Bytecode => Baseline JIT => Optimized JIT

Slide 27

Slide 27 text

Baseline JIT Baseline JIT is simple unoptimized “Baseline” assembler. “Baseline” mean optimization baseline. It’s fast than Bytecode but slower than native optimized codes.

Slide 28

Slide 28 text

Optimized JIT Optimized JIT is fastest program in javascript engine. That is very fast, but cost many cpu cycles to generate and using large heap space to reserve.

Slide 29

Slide 29 text

Deoptimization Deoptimization is convertion from optimized machine language to previous baseline JIT, if infered type become invalid. Generally this caused by unexpected type is passed to optimized function.

Slide 30

Slide 30 text

Deoptimization const id = x => x; const test = obj => { for (let i = 0; i < 100000; i++) { id(obj.x); } } test({x: 1}); test({x: 1, y: 1}); This code will cause deoptimization.

Slide 31

Slide 31 text

Optimization steps(V8) Find Hotspot Bytecode Create TurboFan IR OSR/Compile Function Consume optimization budget Deoptimization

Slide 32

Slide 32 text

Optimization steps(JSC) OSR 100times statement or 6 times function called Deoptimization Bytecode “LL Int” Baseline JIT 1000times statement or 66 times function called DFG JIT FTL JIT Collect profiles

Slide 33

Slide 33 text

Optimization steps(IonMonkey) Collect Profiles Deoptimization Bytecode “LL Int” Simple JIT Find Heaviely looped code Full JIT Create MIR Optimize

Slide 34

Slide 34 text

Types & Inline Caches

Slide 35

Slide 35 text

Types(V8 Map) const foo = { x: 1, y: 2 } {x: {offset: 1}} {y: {offset: 3}} foo.z = 3 {transition: {x: {offset: 1}}, {y: {offset: 3}}} {z: {offset: 4}}

Slide 36

Slide 36 text

Types(Others) Javascript engines has each Map like structure, E.g. JSC Shape. Each Type systems different from each other, but basic idea of these systems are that classificate javascript object by property layout.

Slide 37

Slide 37 text

Inline Cache function x(obj) { return obj.x + obj.y; } x({x: 0, y: 0}); x({x: 1, y: 1}); x({x: 2, y: 2}); Search “x” and “y” Direct access to “x” and “y” x y 1st time 2nd time or later

Slide 38

Slide 38 text

Inline Caches Inline cache is fast path for property access. Almost all case hasn’t any problem, but javascript is very dynamic language, so if property is updated, property cache will update too. Inline cache has below state. Monomorphic Polymorphic Megamorphic

Slide 39

Slide 39 text

Inline Cache States(V8) “Monomorphic” Ideal state. Only one Map. “Polymorphic” Has some Maps, but still fast. “Megamorphic” Bad state, can’t create fast path.

Slide 40

Slide 40 text

Appendix Garbage Collector

Slide 41

Slide 41 text

GC Specs V8 Javascript Core SpiderMonkey Orinoco GC Concurrent Incremental Parallel MarkCompat Generational Copying Concise Riptide GC Concurrent Incremental Parallel MarkCompat Generational Conversative Copying ?

Slide 42

Slide 42 text

Credits 4VNNFSWFDUPSDSFBUFECZNBDSPWFDUPSXXXGSFFQJLDPN IUUQTXXXQOHBSUTDPNFYQMPSF3IJOPDFSPT'SFF1/(*NBHF %FTJHOWFDUPSDSFBUFECZGSFFQJLXXXGSFFQJLDPN 1FPQMFWFDUPSDSFBUFECZGSFFQJLXXXGSFFQJLDPN +BWB4DSJQUFOHJOFGVOEBNFOUBMT4IBQFTBOE*OMJOF$BDIFT IUUQTNBUIJBTCZOFOTCFOPUFTTIBQFTJDT *OUSPEVDJOH3JQUJEF8FC,JU`T3FUSFBUJOH8BWFGSPOU$PODVSSFOU(BSCBHF$PMMFDUPS IUUQTXFCLJUPSHCMPHJOUSPEVDJOHSJQUJEFXFCLJUTSFUSFBUJOHXBWFGSPOUDPODVSSFOUHBSCBHFDPMMFDUPS *PO.POLFZ0WFSWJFX IUUQTXJLJNP[JMMBPSH*PO.POLFZ0WFSWJFX 5SBTIUBMLUIF0SJOPDPHBSCBHFDPMMFDUPS IUUQTWEFWCMPHUSBTIUBML *OUSPEVDJOHUIF8FC,JU'5-+*5 IUUQTXFCLJUPSHCMPHJOUSPEVDJOHUIFXFCLJUGUMKJU #BSF#POFT#BDLFOE IUUQTXFCLJUPSHEPDTC 4PVSDFUP#JOBSZKPVSOFZPG7KBWBTDSJQUFOHJOF &OHMJTIWFSTJPO IUUQTTQFBLFSEFDLDPNCSOTPVSDFUPCJOBSZKPVSOFZPGWKBWBTDSJQUFOHJOFFOHMJTIWFSTJPO