Javascript解析引擎&内存泄漏

 

Javascript解析引擎&内存泄漏

关键字: js, 解析引擎

本篇博客主要是整理js解析引擎相关知识点。

----------------------------------------------------------

http://blog.csdn.net/aimingoo/archive/2008/07/23/2700248.aspx

 

SpiderMonkey JavaScript引擎的源代码中，我们得知道，执行引擎并不直接执行代码，而是先将代码

文本分析(parser)成代码树，再按规则执行代码树中的指令结点(op)。指令在JS中总是确定的，例如源代码

中是FOR，那么总是JSOP_FOR*这个操作码。但是，指令所使用的参数却不是确定的，而是通过参数名绑

定到一个具体的操作数。参数名是字符串，也就是标识符；操作数则位于该代码上下文所使用的栈中。这

个栈中的操作数使用slot位置来表示。

-----------------------------------------------------------

From: http://www.blogjava.net/tim-wu/archive/2006/05/29/48729.html

常规循环引用内存泄漏和Closure内存泄漏

要了解javascript的内存泄漏问题，首先要了解的就是javascript的GC原理。

我记得原来在犀牛书《JavaScript: The Definitive Guide》中看到过，IE使用的GC算法是计数器，因此只碰到循环 引用就会造成memory leakage。后来一直觉得和观察到的现象很不一致，直到看到Eric的文章，才明白犀牛书的说法没有说得很明确，估计该书成文后IE升级过算法吧。在 IE 6中，对于javascript object内部，jscript使用的是mark-and-sweep算法，而对于javascript object与外部object(包括native object和vbscript object等等)的引用时，IE 6使用的才是计数器的算法。

Eric Lippert在http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx一文中提到IE 6中JScript的GC算法使用的是nongeneration mark-and-sweep。对于javascript对算法的实现缺陷，文章如是说：
"The benefits of this approach are numerous, but the principle benefit is that circular references are not leaked unless the circular reference involves an object not owned by JScript. "
也就是说，IE 6对于纯粹的Script Objects间的Circular References是可以正确处理的，可惜它处理不了的是JScript与Native Object(例如Dom、ActiveX Object)之间的Circular References。
所以，当我们出现Native对象(例如Dom、ActiveX Object)与Javascript对象间的循环引用时，内存泄露的问题就出现了。当然，这个bug在IE 7中已经被修复了［http://www.quirksmode.org/blog/archives/2006/04/ie_7_and_javasc.html］。

-------------------------------------------------------------------------

From: http://jibbering.com/faq/faq_notes/closures.html

 

js内存泄漏的四种模式:

1. Circular References—When mutual references are counted between Internet Explorer's COM infrastructure and any scripting engine, objects can leak memory. This is the broadest pattern.

2. Closures—Closures are a specific form of circular reference that pose the largest pattern to existing Web application architectures. Closures are easy to spot because they rely on a specific language keyword and can be searched for generically.

3. Cross-Page Leaks—Cross-page leaks are often very small leaks of internal book-keeping objects as you move from site to site. We'll examine the DOM Insertion order issue, along with a workaround that shows how small changes to your code can prevent the creation of these book-keeping objects.

4. Pseudo-Leaks—These aren't really leaks, but can be extremely annoying if you don't understand where your memory is going. We'll examine the script element rewriting and how it appears to leak quite a bit of memory, when it is really performing as required.