{"id":783,"date":"2016-07-05T11:45:49","date_gmt":"2016-07-05T11:45:49","guid":{"rendered":"http:\/\/blog.mozilla.org\/javascript\/?p=783"},"modified":"2017-12-21T13:47:25","modified_gmt":"2017-12-21T13:47:25","slug":"ionmonkey-evil-on-your-behalf","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/javascript\/2016\/07\/05\/ionmonkey-evil-on-your-behalf\/","title":{"rendered":"IonMonkey: Evil on your behalf"},"content":{"rendered":"
\n
\u201cProgrammers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.\u201d<\/span><\/div>\n
\u2014 Donald Knuth<\/a><\/span>
\n<\/span><\/div>\n<\/blockquote>\n
This quote is not as well known as the end of it<\/span>, often shortened to \u201cpremature optimization is the root of all evil<\/a><\/em>\u201d.<\/span> I<\/span>t highlights why you should prefer code which is more maintainable, as long as the performance of it does not <\/span>impact the user.<\/span><\/div>\n
 <\/div>\n

Maintainable code is a matter of taste. For example, we often teach students to dislike \u201cgoto\u201d in C, but the best error handling code<\/a> I <\/span>have seen (<\/span>in C) comes from the Linux kernel, and is using \u201cgoto\u201d’s. Maintainable code in JavaScript is also a matter of taste<\/span>. S<\/span>ome might prefer <\/span>using <\/span>ES6 features, <\/span>while others <\/span>might prefer functional programing approach with lambdas or even us<\/span>ing<\/span> some framework.<\/span><\/p>\n

In most cases, we add more abstractions, we add more memory, and more code<\/span>, t<\/span>hus giving even more reasons <\/span>for the code to be slower<\/span>. Today, I will introduce <\/span>two <\/span>optimizations <\/span>that<\/span> made it into IonMonkey, which are known <\/span>as <\/span>Scalar Replacement and Branch Pruning.<\/span><\/div>\n
 <\/div>\n

Scalar Replacement<\/span><\/h2>\n
 <\/div>\n
The goal of Scalar Replacement is to reduce the amount of memory needed to represent objects in memory, by replacing object properties with local variables.\u00a0 Then, when all objects properties are replaced, we can remove the object and avoid its memory overhead (i-e allocation, accesses, and GCs).<\/span><\/div>\n
 <\/div>\n
For example, in the following code, we have a few functions for manipulating complex numbers as a tuple of a real and an imaginary part.\u00a0 When compiling the norm_multiply<\/code> function, the <\/span>I<\/span>nlining phase will bake the code of complex<\/code> and norm<\/code> functions inside the norm_multiply<\/code> function.<\/span><\/div>\n
\n
\r\nfunction complex(r, i) {\r\n    return { r: r, i: i };\r\n}\r\nfunction norm(c) {\r\n    return Math.sqrt(c.r * c.r + c.i * c.i);\r\n}\r\nfunction norm_multiply(a, b) {\r\n    var mul = complex(a.r * b.r - a.i * b.i, a.r * b.i + a.i * b.r);\r\n    return norm(mul);\r\n}<\/code><\/pre>\n
Thus, Scalar Replacement handles the object coming from the complex<\/code> function, and replaces it by two local variables.\u00a0 The object is no longer needed and IonMonkey effectively runs the following code:
\n<\/span><\/div>\n
\r\nfunction norm_multiply(a, b) {\r\n\u00a0\u00a0\u00a0 var mul_r = a.r * b.r - a.i * b.i;\r\n\u00a0\u00a0\u00a0 var mul_i = a.r * b.i + a.i * b.r;\r\n\u00a0\u00a0\u00a0 return Math.sqrt(mul_r * mul_r + mul_i * mul_i);\r\n}<\/code><\/pre>\n
This optimization works by looking at one object, then determin<\/span>ing<\/span> if th<\/span>e <\/span>object never escape<\/span>s<\/span> (detailed below)<\/span>, that all properties are known, and <\/span>that <\/span>it is not mixed with other objects.<\/span><\/div>\n
 <\/div>\n
Once all these predicates are validated, this optimization emulates the content of the memory of the object while traversing the control flow graph of the program<\/span>, t<\/span>hereby replacing all property accesses <\/span>with reads of <\/span>local variables.<\/span><\/div>\n
 <\/div>\n
Once all property accesses are removed, the alloca<\/span>ted<\/span> object is used <\/span>only <\/span>by a few recover instructions<\/a><\/span> that<\/span> are capturing the object state at across the control flow graph. Each object state is an instruction <\/span>that<\/span> serve<\/span>s<\/span> no purpose during the execution, but uses the Recover Instructions mechanism to set the content of the properties on <\/span>the deoptimization path (bailout) to Baseline compiled code<\/span>. At the end, the Sink \/<\/span> Dead Code Elimination phase<\/span>s<\/span> convert the object allocation into a recovered instruction, as it is only used by the object state instructions.<\/span><\/div>\n
 <\/div>\n
Escape Analysis<\/span><\/h3>\n
 <\/div>\n
One of the biggest limitation of Scalar Replacement is that it is limited to objects <\/span>that do not escape<\/span>.<\/span><\/div>\n
 <\/div>\n
We have multiple way<\/span>s<\/span> for an object to escape:<\/span><\/div>\n