問題描述

這主要是一個出于好奇的問題.考慮以下函數

This is mostly an out-of-curiosity question. Consider the following functions

var closure ;
function f0() {
    var x = new BigObject() ;
    var y = 0 ;
    closure = function(){ return 7; } ;
}
function f1() {
    var x = BigObject() ;
    closure =  (function(y) { return function(){return y++;} ; })(0) ;
}
function f2() {
    var x = BigObject() ;
    var y = 0 ;
    closure = function(){ return y++ ; } ;
}

在每種情況下，在函數執行后，(我認為)沒有辦法到達 x，因此 BigObject 可以被垃圾回收，只要因為 x 是對它的最后引用.每當計算函數表達式時，頭腦簡單的解釋器都會捕獲整個作用域鏈.(一方面，您需要這樣做才能使對 eval 的調用正常工作——下面的示例).更聰明的實現可能會在 f0 和 f1 中避免這種情況.更智能的實現將允許保留 y，但不允許保留 x，這是 f2 高效所必需的.

In every case, after the function has been executed, there is (I think) no way to reach x and so the BigObject can be garbage collected, as long as x is the last reference to it. A simple minded interpreter would capture the whole scope chain whenever a function expression is evaluated. (For one thing, you need to do this to make calls to eval work -- example below). A smarter implementation might avoid this in f0 and f1. An even smarter implementation would allow y to be retained, but not x, as is needed for f2 to be efficient.

我的問題是現代 JavaScript 引擎(JaegerMonkey、V8 等)如何處理這些情況?

My question is how do the modern JavaScript engines (JaegerMonkey, V8, etc.) deal with these situations?

最后，這里有一個例子說明變量可能需要保留，即使它們從未在嵌套函數中提及.

Finally, here is an example that shows that variables may need to be retained even if they are never mentioned in the nested function.

var f = (function(x, y){ return function(str) { return eval(str) ; } } )(4, 5) ;
f("1+2") ; // 3
f("x+y") ; // 9
f("x=6") ;
f("x+y") ; // 11

但是，有一些限制可以防止人們以編譯器可能遺漏的方式潛入對 eval 的調用.

However, there are restrictions that prevent one from sneaking in a call to eval in ways that might be missed by the compiler.

推薦答案

存在限制阻止您調用靜態分析會遺漏的 eval 并不是真的:只是對 eval 的此類引用運行在全球范圍.請注意，這是 ES5 與 ES3 相比的一個變化，其中對 eval 的間接和直接引用都在本地范圍內運行，因此，我不確定是否有任何東西實際上基于這一事實進行了任何優化.

It's not true that there are restrictions that prevent you from calling eval that would be missed by static-analysis: it's just that such references to to eval run in the global scope. Note that this is a change in ES5 from ES3 where indirect and direct references to eval both ran in the local scope, and as such, I'm unsure whether anything actually does any optimizations based upon this fact.

一個明顯的測試方法是讓 BigObject 成為一個非常大的對象，并在運行 f0–f2 后強制執行 gc.(因為，嘿，盡管我想我知道答案，但測試總是更好！)

An obvious way to test this is to make BigObject be a really big object, and force a gc after running f0–f2. (Because, hey, as much as I think I know the answer, testing is always better!)

那么……

var closure;
function BigObject() {
  var a = '';
  for (var i = 0; i <= 0xFFFF; i++) a += String.fromCharCode(i);
  return new String(a); // Turn this into an actual object
}
function f0() {
  var x = new BigObject();
  var y = 0;
  closure = function(){ return 7; };
}
function f1() {
  var x = new BigObject();
  closure =  (function(y) { return function(){return y++;}; })(0);
}
function f2() {
  var x = new BigObject();
  var y = 0;
  closure = function(){ return y++; };
}
function f3() {
  var x = new BigObject();
  var y = 0;
  closure = eval("(function(){ return 7; })"); // direct eval
}
function f4() {
  var x = new BigObject();
  var y = 0;
  closure = (1,eval)("(function(){ return 7; })"); // indirect eval (evaluates in global scope)
}
function f5() {
  var x = new BigObject();
  var y = 0;
  closure = (function(){ return eval("(function(){ return 7; })"); })();
}
function f6() {
  var x = new BigObject();
  var y = 0;
  closure = function(){ return eval("(function(){ return 7; })"); };
}
function f7() {
  var x = new BigObject();
  var y = 0;
  closure = (function(){ return (1,eval)("(function(){ return 7; })"); })();
}
function f8() {
  var x = new BigObject();
  var y = 0;
  closure = function(){ return (1,eval)("(function(){ return 7; })"); };
}
function f9() {
  var x = new BigObject();
  var y = 0;
  closure = new Function("return 7;"); // creates function in global scope
}

我已經為 eval/Function 添加了測試，看起來這些也是有趣的案例.f5/f6 之間的區別很有趣，因為 f5 實際上與 f3 完全相同，因為它實際上是相同的閉包函數；f6 只返回一些曾經評估過的東西，并且由于尚未評估 eval，編譯器無法知道其中沒有對 x 的引用.

I've added tests for eval/Function, seeming these are also interesting cases. The different between f5/f6 is interesting, because f5 is really just identical to f3, given what is really an identical function for closure; f6 merely returns something that once evaluated gives that, and as the eval hasn't yet been evaluated, the compiler can't know that there is no reference to x within it.

js> gc();
"before 73728, after 69632, break 01d91000
"
js> f0();
js> gc(); 
"before 6455296, after 73728, break 01d91000
"
js> f1(); 
js> gc(); 
"before 6455296, after 77824, break 01d91000
"
js> f2(); 
js> gc(); 
"before 6455296, after 77824, break 01d91000
"
js> f3(); 
js> gc(); 
"before 6455296, after 6455296, break 01db1000
"
js> f4(); 
js> gc(); 
"before 12828672, after 73728, break 01da2000
"
js> f5(); 
js> gc(); 
"before 6455296, after 6455296, break 01da2000
"
js> f6(); 
js> gc(); 
"before 12828672, after 6467584, break 01da2000
"
js> f7(); 
js> gc(); 
"before 12828672, after 73728, break 01da2000
"
js> f8(); 
js> gc(); 
"before 6455296, after 73728, break 01da2000
"
js> f9(); 
js> gc(); 
"before 6455296, after 73728, break 01da2000
"

SpiderMonkey 在除 f3、f5 和 f6 之外的所有內容上都對 GC "x" 顯示.

SpiderMonkey appears to GC "x" on everything except f3, f5, and f6.

除非在仍然存在的任何函數的作用域鏈中直接 eval 調用，否則它會盡可能地顯示(即，如果可能，y 和 x).(即使該函數對象本身已被 GC 處理并且不再存在，如 f5 中的情況，這在理論上意味著它可以 GC x/y.)

It appears to as much as possible (i.e., when possible, y, as well as x) unless there is direct eval call within the scope-chain of any function that still exists. (Even if that function object itself has been GC'd and no longer exists, as is the case in f5, which theoretically means that it could GC x/y.)

gsnedders@dolores:~$ v8 --expose-gc --trace_gc --shell foo.js
V8 version 3.0.7
> gc();
Mark-sweep 0.8 -> 0.7 MB, 1 ms.
> f0();
Scavenge 1.7 -> 1.7 MB, 2 ms.
Scavenge 2.4 -> 2.4 MB, 2 ms.
Scavenge 3.9 -> 3.9 MB, 4 ms.
> gc();   
Mark-sweep 5.2 -> 0.7 MB, 3 ms.
> f1();
Scavenge 4.7 -> 4.7 MB, 9 ms.
> gc();
Mark-sweep 5.2 -> 0.7 MB, 3 ms.
> f2();
Scavenge 4.8 -> 4.8 MB, 6 ms.
> gc();
Mark-sweep 5.3 -> 0.8 MB, 3 ms.
> f3();
> gc();
Mark-sweep 5.3 -> 5.2 MB, 17 ms.
> f4();
> gc();
Mark-sweep 9.7 -> 0.7 MB, 5 ms.
> f5();
> gc();
Mark-sweep 5.3 -> 5.2 MB, 12 ms.
> f6();
> gc();
Mark-sweep 9.7 -> 5.2 MB, 14 ms.
> f7();
> gc();
Mark-sweep 9.7 -> 0.7 MB, 5 ms.
> f8();
> gc();
Mark-sweep 5.2 -> 0.7 MB, 2 ms.
> f9();
> gc();
Mark-sweep 5.2 -> 0.7 MB, 2 ms.

V8 在除 f3、f5 和 f6 之外的所有內容上都出現在 GC x 上.這與 SpiderMonkey 相同，參見上面的分析.(但是請注意，這些數字不夠詳細，無法判斷 y 是否在 x 沒有被 GC 時，我沒有費心去調查這個.)

V8 appears to GC x on everything apart from f3, f5, and f6. This is identical to SpiderMonkey, see analysis above. (Note however that the numbers aren't detailed enough to tell whether y is being GC'd when x is not, I've not bothered to investigate this.)

我不想再運行這個了，但不用說行為與 SpiderMonkey 和 V8 相同.沒有 JS shell 更難測試，但隨著時間的推移是可行的.

I'm not going to bother running this again, but needless to say behaviour is identical to SpiderMonkey and V8. Harder to test without a JS shell, but doable with time.

在 Linux 上構建 JSC 很痛苦，而 Chakra 不能在 Linux 上運行.我相信 JSC 對上述引擎有相同的行為，如果 Chakra 沒有，我會感到驚訝.(做任何更好的事情很快就會變得非常復雜，做任何更糟糕的事情，好吧，你幾乎永遠不會做 GC 并且有嚴重的內存問題......)

Building JSC is a pain on Linux, and Chakra doesn't run on Linux. I believe JSC has the same behaviour to the above engines, and I'd be surprised if Chakra didn't have too. (Doing anything better quickly becomes very complex, doing anything worse, well, you'd almost never be doing GC and have serious memory issues…)

這篇關于JavaScript 運行時如何表示閉包和作用域的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！