Understanding Javascript Engines

Understanding Javascript Engines

• 1.
  JavaScript EnginesPop thehood
• 2.
  z = x+ y
• 3.
  Executing z= x + yRead operation from memoryGet location of x and yRead values for x and y Unbox x and y.Choose meaning of “+”, perform “+”Save z to memoryDo garbage.
• 4.
  1. Read operationfrom memory…String “z = x + y” is passed into tokenizer.Webkit uses Flex (LEX)Accommodate semi colon insertion, etc.Tokenizer output fed to parser Webkit uses Bison, bottom up shift reduce parserGecko has top down parserStatement now available as Abstract Syntax Tree (AST)
• 5.
  2. Get locationsof x and yX & Y could be number, string, object, null, undefined, array, etc. Offsets directly available for primitivesValues also depend on context of executionClosures (activation contexts)Local VariablesObject propertiesScope modifiers – eval, with, etc.
• 6.
  2. Getvalues of x – ArrayIf x is a actually array - obj[x]Dense array have offsetsCreated using 0..N or pushGecko creates sparse array on N..0Adding obj[“name”] fails optimization
• 7.
  2. Getvalues of x – ObjectIf X is an object property (obj.x)Looks up current object or up the prototype chainInline Cache (IC) the valueObjects have shape – {x:1} is different from {x:1,y:2}Webkit stores memory offsets in hidden classesNew shape created for every new property.IC can read from prototype without walking treeClosures only save path, still have to walk every time. OpCodes generated for each shapeObj.x ==> read shape1[member1]
• 8.
  3. Read boxedinput …JavaScript variable assignments are un-typed. Assignments stored as boxed inputsx could be (int32 | 100) – indicating type and valueJavascript numbers are IEEE-754 floating point.Who cares, just use 32 bit to optimize. Overflow to doubles. Ways to Box values (ref)Tagging the LSBs (ref)Nan Boxing (ref) – 51 bit of NaN space for non-doubles (Webkit)Nun Boxing (favor doubles in NAN – Mozilla pun)
• 9.
  4. Unboxx and yFrom box, infer type and value, represent it in native type
• 10.
  Int32 x =100;
• 11.
  From NunBoxed Values
• 12.
  0x400c 0000 |0x0000 0000 = not a nan, so double (3.5)
• 13.
  0xFFFF0001 | 0x00000040 = Nan space, so Int32 (0x0000 0040)
• 14.
  From NanBoxed Values(0xFFFF80 00000040)
• 15.
  Mask to getpointer, shift to get double
• 16.
  X64 portability, fitsin register, but harder to decode5. Perform “+” : InterpreterIf (typeof x == int32 && typeof y == int32)
• 17.
  result = x<operator> y
• 18.
  If (result overflows),result = float
• 19.
  If (result Nan),result = NaN.
• 20.
  If (typeof x== int32 && typeof y === float)
• 21.
  result = CoarceToFloat(x)+ y
• 22.
  // Same sanitychecks
• 23.
  …..
• 24.
  If (typeof x=== Object)
• 25.
  …. 5. Perform “+” : Basic JITIf type of x and y are known,
• 26.
  generate opcodes
• 27.
  Fall to opcodewhen routine is hit.
• 28.
  Save cost ofboxing, unboxing.
• 29.
  Determined opcode Pathsfor each shape
• 30.
  Multiple shapes meanmultiple if-else branches
• 31.
  Still have tocheck for validity/dirtiness of opcpdes
• 32.
  Typical JagerMonkeyJITing5. Perform “+” : Typed JITObserve and identify hot code
• 33.
  70 iterations
• 34.
  Crankshaft – accordingto profiler
• 35.
  Other heuristics
• 36.
  Execute opcode routinefor specific type
• 37.
  Initial compilation cost
• 38.
  OpCodes may bethrown away if types change
• 39.
  Fallback to non-optimizedversion (Performance fault)
• 40.
  Classic Tracemonkey5. Perform “+” : Next Gen JITStatic analysis of code to “prove” types
• 41.
  Reduce checks, ensureonly one path taken at all times.
• 42.
  Type stable Javascript
• 43.
  IonMonkey Internals.
• 44.
  Use multicore processors
• 45.
  To box/unbox values
• 46.
  To generate compiledopcodes (Chakra)5. Perform “+” : GPU EnabledUsed by WebGL and Canvas render computation routines
• 47.
  Shaders and alphachannel (no direct JS code)
• 48.
  Super fast floatingpoint math
• 49.
  Note that variablesis strongly typed as Blobs5. Perform “+” : DatatypesStrings
• 50.
  Substring is O(1),Concat also optimized
• 51.
  Concat fault onOpera, Chrome
• 52.
  Array
• 53.
  Denser the better
• 54.
  Named property issparse in FF, IE
• 55.
  Iterate using index,not for:in or functional
• 56.
  Functions
• 57.
  F() faster thanf.call(), f.apply().
• 58.
  Using arguments slowsdown execution5. Perform “+” : DatatypesObjects
• 59.
  Prototypes are betterthan closures
• 60.
  Exceptions
• 61.
  Try is mostlyfree, catch is expensive
• 62.
  May cause optimizerto stop
• 63.
  Eval and With
• 64.
  Cause scope suddenchange, prevent JIT6. Save ZBox “z” and put it on heap if required.
• 65.
  Leave “z” inregister if used subsequently
• 66.
  Create shape for“z” if object7. Garbage CollectionMark and Sweep
• 67.
  Causes GC topause main routine
• 68.
  Jittery animation, unresponsiveUI thread
• 69.
  Incremental GC
• 70.
  Mark and sweeponly parts
• 71.
  Generational GC
• 72.
  Separate objects innursery and tenured areas
• 73.
  Promoting young toold is expensive
• 74.
  Combine Generational andIncremental
• 75.
  Frequent young cleanup,occasional old cleanupChanges due to ECMA.nextBlock Scope reduces variable lookups (let, var)
• 76.
  “Yeild” may needto save current context
• 77.
  Blob Data type– boxing/unboxing issues
• 78.
  Classes === ConcreteShapes ?
• 79.
  Syntactic sugar, noimpact
• 80.
  Assignment de-structuring
• 81.
  Promises, modules, etc.ConclusionsDon’twrite any code
• 82.
  Practice type safety
• 83.
  Leave hot loopsalone – don’t create shapes in them
• 84.
  Make arrays dense
• 85.
  Avoid operations thatrequire different type coercion every time.@nparashuramhttp://nparashuram.com