The document discusses how JavaScript engines work under the hood to execute code. It explains that engines first tokenize and parse code into an abstract syntax tree. Variables are then located in memory and their values retrieved, which can involve lookups in objects or arrays. Values are boxed and typed for operations, which engines try to optimize through just-in-time compilation by tracking types. Operations are performed and results are stored, with garbage collection maintaining memory. Future ECMAScript changes may impact these processes. The conclusion advocates type safety, dense arrays, and avoiding operations requiring repeated coercion.

1. JavaScript Engines Pop the hood

2. z = x + y

3. Executing z = x + y Read operation from memory Get location of x and y Read values for x and y Unbox x and y. Choose meaning of “+”, perform “+” Save z to memory Do garbage.

4. 1. Read operation from 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 parser Gecko has top down parser Statement now available as Abstract Syntax Tree (AST)

5. 2. Get locations of x and y X & Y could be number, string, object, null, undefined, array, etc. Offsets directly available for primitives Values also depend on context of execution Closures (activation contexts) Local Variables Object properties Scope modifiers – eval, with, etc.

6. 2. Get values of x – Array If x is a actually array - obj[x] Dense array have offsets Created using 0..N or push Gecko creates sparse array on N..0 Adding obj[“name”] fails optimization

7. 2. Get values of x – Object If X is an object property (obj.x) Looks up current object or up the prototype chain Inline Cache (IC) the value Objects have shape – {x:1} is different from {x:1,y:2} Webkit stores memory offsets in hidden classes New shape created for every new property. IC can read from prototype without walking tree Closures only save path, still have to walk every time. OpCodes generated for each shape Obj.x ==> read shape1[member1]

8. 3. Read boxed input … JavaScript variable assignments are un-typed. Assignments stored as boxed inputs x could be (int32 | 100) – indicating type and value Javascript 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)

10. Int32 x = 100;

11. From NunBoxed Values

12. 0x400c 0000 | 0x0000 0000 = not a nan, so double (3.5)

13. 0xFFFF0001 | 0x0000 0040 = Nan space, so Int32 (0x0000 0040)

14. From NanBoxed Values (0xFFFF80 00000040)

15. Mask to get pointer, shift to get double

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 sanity checks

23. …..

24. If (typeof x === Object)

26. generate opcodes

27. Fall to opcode when routine is hit.

28. Save cost of boxing, unboxing.

29. Determined opcode Paths for each shape

30. Multiple shapes mean multiple if-else branches

31. Still have to check for validity/dirtiness of opcpdes

33. 70 iterations

34. Crankshaft – according to profiler

35. Other heuristics

36. Execute opcode routine for specific type

37. Initial compilation cost

38. OpCodes may be thrown away if types change

39. Fallback to non-optimized version (Performance fault)

41. Reduce checks, ensure only one path taken at all times.

42. Type stable Javascript

43. IonMonkey Internals.

44. Use multicore processors

45. To box/unbox values

47. Shaders and alpha channel (no direct JS code)

48. Super fast floating point math

50. Substring is O(1), Concat also optimized

51. Concat fault on Opera, Chrome

52. Array

53. Denser the better

54. Named property is sparse in FF, IE

55. Iterate using index, not for:in or functional

56. Functions

57. F() faster than f.call(), f.apply().

59. Prototypes are better than closures

60. Exceptions

61. Try is mostly free, catch is expensive

62. May cause optimizer to stop

63. Eval and With

65. Leave “z” in register if used subsequently

67. Causes GC to pause main routine

68. Jittery animation, unresponsive UI thread

69. Incremental GC

70. Mark and sweep only parts

71. Generational GC

72. Separate objects in nursery and tenured areas

73. Promoting young to old is expensive

74. Combine Generational and Incremental

76. “Yeild” may need to save current context

77. Blob Data type – boxing/unboxing issues

78. Classes === Concrete Shapes ?

79. Syntactic sugar, no impact

80. Assignment de-structuring

82. Practice type safety

83. Leave hot loops alone – don’t create shapes in them

84. Make arrays dense