You don't know. Javascript--item18 JScript bugs and memory management

1. JScript bugs

IE's ECMAScript implementation JScript seriously confuses the name function expressions, and many people come out against the name function expressions, and even now the one version that is still in use (version 5.8 used in IE8) still has the following problems.

Let's take a look at the IE in the implementation of the mistakes made, as the saying goes, we know that can baizhanbudai. Let's take a look at a few examples below:

Example 1: identifier of a function expression leaked to an external scope

varfunction g(){};typeof// "function"

As we said earlier, the identifier of a named function expression is invalid outside scope, but JScript is clearly a violation of this specification, the above example of the identifier G is parsed into a function object, this is a mess, a lot of difficult to find bugs are caused by this reason.

Note: IE9 seems to have fixed the problem later

Example 2: Use a named function expression as both a function declaration and a function expression

typeof// "function"varfunction g(){};

In an attribute environment, a function declaration takes precedence over any expression being parsed, and the example above shows that JScript actually treats a named function expression as a function declaration because it parses G before actually declaring it.

This example leads to the next example.

Example 3: A named function expression creates two distinct function objects!

varfunction g(){// false‘foo‘// undefined

See here, people will feel the problem is serious, because to modify any one object, the other has nothing to change, this is too bad. In this example, it is possible to create 2 different objects, that is to say, if you want to modify the properties of F to save a certain information and then take it for granted by referencing the same property with the same name as g of the same object, the problem is large, because it is not possible at all.

Let's look at a slightly more complicated example:

Example 4: Conditional statement blocks are ignored in order to parse function declarations only

varfunction g() {     return1;};if (false) {    function g(){    return2;  // 2

This bug is much more difficult to find, but the cause of the bug is very simple. First, G is parsed as a function declaration, because function declarations in JScript are not constrained by conditional code blocks, so in this very bad if branch, G is treated as another function g () {return 2}, which is also declared once. Then, all the "regular" expressions are evaluated, and F is given a reference to another newly created object. Since the expression is evaluated, it never goes into "This hateful if branch, so F will continue to refer to the first function g () {return 1}. Analysis here, the problem is clear: if you are not careful enough to call G in F, then will call a irrelevant G function object.

You might ask, what is the difference between a different object and a Arguments.callee? Let's take a look at:

varfunction g(){      return [        arguments.callee == f,        arguments.callee == g      // [true, false]// [false, true]

As you can see, the Arguments.callee reference has always been called function, which is actually a good thing to explain later.

Another interesting example is the use of a named function expression in an assignment statement that does not include a declaration:

(function(){  f = function f(){};})();

According to the analysis of the code, we originally wanted to create a global attribute F (Note that it is not confused with the General anonymous function, which is used with the name of the declaration), JScript is here to make a mess, first of all, he interpreted the expression as a function declaration, So the left F is declared as a local variable (as in the General anonymous function), and then when the function executes, f is already defined, and the Right function f () {} is directly assigned to the local variable F, so f is not a global attribute at all.

Knowing that JScript is such a pervert, we have to prevent these problems in time, first of all to prevent the identifier leak with the external scope, and secondly, should never refer to the identifier used as the function name; remember that annoying identifier g in the previous example? If we can avoid any unnecessary trouble when G does not exist. Therefore, the key is to always refer to the function through F or arguments.callee. If you use a named function expression, you should only use that name when debugging. Finally, keep in mind that it is important to clean up functions that are incorrectly created during the declaration of a named function expression.

2. JScript Memory Management

Knowing that these non-conforming code parsing bugs, if we use it, we will find that the memory is actually problematic, to see an example:

var f = (function(){  if (true) {    returnfunction g(){};  }  returnfunction g(){};})();

We know that this anonymous function calls the returned function (the function with the identifier g) and assigns the value to the outer F. We also know that a named function expression results in an extra function object that is not the same as the returned function object. So the extra G-function died in the closure of the return function, so the memory problem came up. This is because the functions inside the IF statement are declared in the same scope as G. In this case, unless we explicitly break the reference to the G function, it always occupies memory.

var f = (function(){  var f, g;  if (true) {    function g(){};  }  else {    function g(){};  }  // 设置g为null以后它就不会再占内存了  null;  return f;})();

By setting G to null, the garbage collector reclaims the implicit function referenced by G, and in order to validate our code, let's do some testing to make sure our memory is recycled.

Test

The test is simply that the named function expression creates 10,000 functions and then saves them in an array. Wait a minute and see how much memory these functions occupy. Then, disconnect the references and repeat the process. Here is the test code:

 function createfn(){  return( function(){    varFif(true) {f = function F(){        return ' Standard ';    }; }Else if(false) {f = function F(){        return ' Alternative ';    }; }Else{f = function F(){        return ' fallback ';    }; }//var F = null;    returnF })();}vararr = []; for(varI=0; I <10000; i++) {Arr[i] = Createfn ();}

You can see the following results by running Task Manager in Windows XP SP2:

ie7 : Without ' < Span class= "hljs-literal" >null  ': 7.6  k ->  20.3  K with  ' null   ': 7.6  k< Span class= "hljs-function" >-> 18  kie8 : Without ' null   ': 14  K->  29.7  K  With  '   k->  27  K 

As we expected, displaying a disconnect reference frees up memory, but frees up a lot of memory, and 10,000 function objects release approximately 3M of memory, which is not much of a small script, but it is necessary for large programs, or for long periods of time running on low-memory devices.

Copyright NOTICE: This article is the original article, reproduced please specify: http://blog.csdn.net/i10630226

You don't know. Javascript--item18 JScript bugs and memory management