javascript程序的動態(tài)行為分析外文翻譯（節(jié)選）

1、<p>　　1800單詞，1萬英文字符，3600漢字</p><p>　　出處：Richards G, Lebresne S, Burg B, et al. An analysis of the dynamic behavior of JavaScript programs[C]// Acm Sigplan Conference on Programming Language Design &

2、Implementation. ACM, 2010:1-12.</p><p>　　An Analysis of the Dynamic Behavior of JavaScript Programs</p><p>　　Gregor Richards Sylvain Lebresne Brian Burg Jan Vitek</p><p><b>

3、;　　Abstract</b></p><p>　　The JavaScript programming language is widely used for web programming and, increasingly, for general purpose computing. As such, improving the correctness, security and perfor

4、mance of JavaScript applications has been the driving force for research in type systems, static analysis and compiler techniques for this language. Many of these techniques aim to reign in some of the most dynamic featu

5、res of the language, yet little seems to be known about how programmers actually utilize the language or</p><p>　　Keywords：Dynamic Behavior, Execution Tracing, Dynamic Metrics, Program Analysis, JavaScript&l

6、t;/p><p>　　1. Introduction</p><p>　　JavaScript is an object-oriented language designed in 1995 by Brendan Eich at Netscape to allow non-programmers to extend web sites with client-side executable c

7、ode. Unlike more traditional languages such as Java, C# or even Smalltalk, it does not have classes, and does not encourage encapsulation or even structured programming. Instead JavaScript strives to maximize flexibility

8、. JavaScript’s success is undeniable. As a data point, it is used by 97 out of the web’s 100 most popular sites.2 The l</p><p>　　2. Motivation and Related Work</p><p>　　The original impetus for

9、our interest in JavaScript was to assess the feasibility of a static type system able to successfully and meaningfully type check existing JavaScript programs. Other dynamic languages such as Scheme have had recent succe

10、ss introducing gradual typing systems, but they have stopped short of type checking object-oriented extensions (implemented by macros in Scheme). For JavaScript, Anderson et al. proposed a type system with definite and p

11、otential types, while Heidegger and</p><p>　　Common Assumptions about the dynamic behavior of JavaScript.</p><p>　　We proceed to enumerate the explicit and implicit assumptions that are commonly

12、 found in the literature and in implementations. </p><p>　　1. The prototype hierarchy is invariant. The assumption that the prototype hierarchy does not change after an object is created is so central to the

13、 type system work that chose to not even model prototypes. Research on static analysis typically does not mention prototype updates. Yet, any modification to the prototype hierarchy can potentially impact the control flo

14、w graph of the application just as well as the types of affected objects.</p><p>　　2. Properties are added at object initialization. Folklore holds that there is something akin to an “initialization phase” i

15、n dynamic languages where most of the dynamic activity occurs and after which the application is mostly static. For JavaScript this is embodied by the assumption that most changes to the fields and methods of objects occ

16、ur at initialization, and thus that it is reasonable to assign an almost complete type to objects at creation, leaving a small number of properties as poten</p><p>　　3. Properties are rarely deleted. Removal

17、 of methods or fields is difficult to ccommodate in a type system as it permits nonmonotonic evolution of types that breaks subtyping guarantees usually enforced in modern typed languages. If deletion is an exceptional o

18、ccurrence (and one that can be predicted), one could use potential types for properties that may be deleted in the future. But, this would reduce the benefits of having a type.</p><p>　　system in the first p

19、lace, which is probably why related work chooses to forbid it. Static analysis approaches are usually a bit more tolerant to imprecision and can handle deletes, but we have not found any explanation of its handling in ex

20、isting data flow analysis techniques. </p><p>　　4. The use of eval is infrequent and does not affect semantics. The use of eval on arbitrary strings has the potential of invalidating any results obtained by

21、static analysis or static type checking. Thus many works simply ignore it, while other assume that uses are either trivial or related to deserialization using the JSON protocol . </p><p>　　5. Declared functi

22、on signatures are indicative of types. Type systems for JavaScript typically assume that the declared arity of a function is representative of the way it will be invoked. This is not necessarily the case because JavaScri

23、pt allows</p><p>　　calls with different arities.</p><p>　　6. Program size is modest. Some papers justify very expensive analyses with the explicit assumption that handwritten JavaScript programs

24、 are small, and others implicitly rely on this as they present analyses which would not scale to large systems.</p><p>　　7. Call-site dynamism is low. Some JavaScript implementations such as Google V8 rely o

25、n well-known implementation techniques to optimize JavaScript programs such as creating classes (in the Java sense) for objects and inline caches. These techniques will lead to good performance only if the behavior of Ja

26、vaScript is broadly similar to that of other object-oriented languages</p><p>　　8. Execution time is dominated by hot loops. Trace-based Justin-time compilers such as Trace Monkey rely on the traditional ass

27、umption that execution time is dominated by small loops.</p><p>　　9. Industry benchmarks are representative of JavaScript workloads. Standard enchmark suites such as SunSpider, Dromaeo and V8, are used to tu

28、ne and compare JavaScript implementations and to evaluate the accuracy of static analysis techniques. But conclusions obtained from use of those benchmarks are only meaningful if they accurately represent the range of Ja

29、vaScript workloads in the wild.</p><p>　　The goal of this paper is to provide supporting evidence to either confirm or invalidate these assumptions. We are not disputing the validity of previous research, as

30、 even if a couple of the above assumptions proved to be unfounded, previous work can still serve as a useful starting point for handling full JavaScript. But we do want to highlight limitations to widespread adoption of

31、existing techniques and point to challenges that should be addressed in future research.</p><p>　　Related Work. Until now, to the best of our knowledge, there has been no study of the dynamic behavior of Jav

32、aScript programs of comparable depth or breadth. Ratanaworabhan et al. have performed a similar study concurrently to our own, and its results are similar to ours. There have been studies of JavaScript’s dynamic behavior

33、 as it applies to security, but the behaviors studied were restricted to those particularly relevant to security. We conducted a small scale study of JavaScript and report</p><p>　　3. Tracing and Analysis In

34、frastructure</p><p>　　The tracing infrastructure developed for this paper is based on an instrumented version of the WebKit web browser engine integrated into Apple’s Safari browser. While there are standalo

35、ne interpreters available, they would not be able to deal with the mixture of DOM and AJAX that is commonplace in most Java Scriptenabled sites. For flexibility, analysis is performed offline. Our instrumented browser re

36、cords a trace containing most operations performed by the interpreter (reads, writes, deletes, </p><p>　　4. Conclusion</p><p>　　This paper has provided the first large-scale study of the runtime

37、 behavior of JavaScript programs. We have identified a set of representative real-world programs ranging in size from hundreds of kilobytes to megabytes, using an instrumented interpreter we have recorded multiple traces

38、 per site, and then with an offline analysis</p><p>　　tool we have extracted behavioral information from the traces. We use this information to evaluate a list of nine commonly made assumptions about JavaScr

39、ipt programs. </p><p>　　JavaScript程序的動態(tài)行為分析</p><p><b>　　摘要</b></p><p>　　JavaScript編程語言是廣泛用于web編程的語言，也越來越多地用于特定目的的計算。因此，如何提高正確性、安全性和JavaScript應用程序的性能就成為了推動類型系統(tǒng)分析，靜態(tài)分析和編譯技

40、術研究等領域發(fā)展的動力之一。許多這些技術都旨在研究在一些最具有動態(tài)特性的語言，然而很少人會清楚的知道程序員是如何利用語言的這些特性。在本文中，我們將研究一些廣泛使用JavaScript程序的動態(tài)行為，并分析如何以及為什么使用這些動態(tài)特性。我們將根據(jù)這些JavaScript程序得出具體的動態(tài)程度，并與目前參考文獻中使用的假定數(shù)據(jù)和通用工業(yè)標準中的數(shù)據(jù)進行比較。</p><p>　　關鍵詞：動態(tài)行為；執(zhí)行跟蹤；動態(tài)指

41、標；程序分析；JavaScript</p><p><b>　　1、介紹 </b></p><p>　　JavaScript是一種面向對象的語言，它可以通過客戶端的可執(zhí)行代碼讓用戶實現(xiàn)和網(wǎng)站的交互，它是在1995年由Netscape公司的Brendan Eich設計出的。它不同于Java、C?；騍malltalk這些傳統(tǒng)語言，它不具有類，也不鼓勵封裝，甚至是結構化

42、編程。與之對應的是，JavaScript十分強調編程語言的靈活性。JavaScript的成功是不可否認的。據(jù)相關數(shù)據(jù)顯示，當前最流行的100個網(wǎng)站中有97個都使用了它.同時，JavaScript語言還成為了許多辦公應用、瀏覽器應用以及開發(fā)環(huán)境等的通用計算平臺。它一直被譽為互聯(lián)網(wǎng)界的“匯編語言”，和Java以及Scheme語言類似，JavaScript需要代碼生成工具的解釋。由于這種成功，JavaScript的已經(jīng)贏得了學術界的重視和尊重

43、，而研究人員也開始將目光都集中在三個主要問題：安全性，正確性和性能。安全性可以說是JavaScript所要解決的最緊迫的問題：到目前為止，已經(jīng)發(fā)生了一些利用語言的動態(tài)性能進行惡意攻擊的案例（主要是能夠利用JavaScript訪問和修改共享文件的特點，通過eval函數(shù)植入惡意代碼）。研究人員已經(jīng)提出</p><p><b>　　2、動機及相關工作</b></p><p>

44、;　　我們最初研究JavaScript的動力在于評估一個靜態(tài)類型的系統(tǒng)是否能成功的驗證現(xiàn)有的JavaScript程序。其他動態(tài)語言，如Scheme語言就成功的逐步應用到了類型系統(tǒng)中，但是其他方面的進展就相對有些停滯，比如缺乏有關面向對象的擴展的類型檢查（Scheme中用宏來實現(xiàn)）。對于JavaScript，Anderson等人提出了一種具有明確類型和潛在類型的類型系統(tǒng)，而Heidegger和Thiemann等人則把他們之前的工作向前推進

45、了一步，加入了一些最新的類型，F(xiàn)urr等人則為DRuby提出了一種相關的系統(tǒng)。所有這些類型系統(tǒng)都可以接受目標語言的一些簡單的簡化，但是他們要依靠相當類似假設。舉例來說，Thiemann寫道：“通常情況下，在初始化后幾不會再定義其他的類型了，而且對象的類型也基本不會發(fā)生變化?！?lt;/p><p>　　常見的關于JavaScript的動態(tài)行為的假設。我們將在下文中繼續(xù)列舉一些被公開發(fā)表或約定俗成的假設，這些假設已經(jīng)在參

46、考文獻和具體程序中得到了廣泛的應用。</p><p>　　1.prototype對象的層次結構是不變的。在創(chuàng)建一個新對象時，Prototype層次的結構不會改變的假設對于一個類型系統(tǒng)的運行是非常重要的，因此我們甚至不會選擇給出prototype對象的模型。關于靜態(tài)分析的研究很典型，通常它們不涉及到prototype的更新或變化，然而，任何關于prototype層次結構的改變都有可能影響到應用程序的控制流程，而那些

47、受到影響的對象的類型也會出現(xiàn)變數(shù)。</p><p>　　2.在對象初始化時屬性被添加。大家一般都認為，對于動態(tài)語言來說，存在一個類似于“初始化階段”的時段，大部分的動態(tài)行為在這個時段發(fā)生，而在這個時段后應用程序大多都是靜態(tài)的。那么具體到JavaScript的情形，就是假設作用域和對象方法的大部分變化都是在初始化階段完成的，因此在創(chuàng)建對象時就已經(jīng)確定類型的大部分，只留有一小部分屬性待定這樣的方法就顯得合情合理了。&

48、lt;/p><p>　　3.屬性很少被刪除。在一個類型系統(tǒng)中刪除方法或作用域是很難的，因為這樣一來就等于它允許了類型的發(fā)展非單調，這會破壞現(xiàn)代類型語言中默認執(zhí)行的子類型化保證。如果刪除的是一個特殊的情況（一個可以預測的情況），人們可以對這些未來可能被刪除的屬性使用一些潛在的類型。但是，這樣做會減少我們使用類型系統(tǒng)所帶來的好處，這可能是為什么一些相關的研究禁止這種做法的原因。靜態(tài)分析方法通常更能接受這種不嚴密的做法，也

49、可以對刪除做出處理，但我們到目前還沒有發(fā)現(xiàn)任何關于現(xiàn)有數(shù)據(jù)流分析技術的解釋。</p><p>　　4.使用eval函數(shù)是罕見的而且不影響語義。Eval函數(shù)通常被用來計算任意字符串，它有可能使靜態(tài)分析或靜態(tài)類型檢查得到結果是無效的。因此，很多文獻就直接忽視了它，而另一些文獻則假定這些使用的影響是微不足道的，或者使用這些參考了JSON反序列化協(xié)議。</p><p>　　5.已聲明函數(shù)的特征能夠

50、說明其類型。JavaScript 里的類型系統(tǒng)已經(jīng)聲明的函數(shù)的元數(shù)能夠說明它在調用時所使用的方法，當然這種情況不是必須的，因為JavaScript允許不同元數(shù)的調用。</p><p>　　6.程序的大小是合適的。很多論文都花費大量筆墨明確指出，他們假定所研究的JavaScript程序是一些小型的程序，而且另一些則暗示了這一點，因為他們向大家介紹說現(xiàn)有的理論分析不能擴展到大型系統(tǒng)中去。</p><

51、;p>　　7.調用現(xiàn)場的動態(tài)行為很少。一些出色的JavaScript程序的完善和優(yōu)化，如谷歌的V8 ，需要依賴一些已經(jīng)成名的實現(xiàn)技術，比如對象創(chuàng)建類（就像Java一樣）和內聯(lián)緩存。如果JavaScript的行為大致類似于其它面向對象的語言，這些技術會帶來良好的性能和使用效果。</p><p>　　8.執(zhí)行時間主要由循環(huán)決定。一些基于跟蹤的即時編譯器，比如TraceMonkey等，它們工作的基礎就建立在程序的

52、執(zhí)行時間主要由小循環(huán)決定這個傳統(tǒng)的假設上。</p><p>　　9.行業(yè)基準能夠反映JavaScript的工作負荷。如SunSpider，Dromaeo和V8這樣的基準測試平臺是用來評價和比較JavaScript的實現(xiàn)性能和計算靜態(tài)分析技術的準確性的。但是，從使用這些基準測試平臺得到的結論只有在一種情況下是有意義的，那就是它們能夠準確地反映出在現(xiàn)實世界中運行的JavaScript程序的工作負荷區(qū)間。</p&

53、gt;<p>　　本文的目的是提供支持或否定以上假設的證據(jù)。我們不是要質疑以前的研究成果的準確性，即使上述假設的一部分是被證明毫無依據(jù)的，以前的研究成果仍然可以為我們研究JavaScript提供一個有用的基礎和出發(fā)點。但是我們想要強調這些已經(jīng)廣泛采用的現(xiàn)有技術的限制，并且指出在今后的研究中要面臨的挑戰(zhàn)。</p><p>　　相關工作。到目前為止，據(jù)我們所知，還沒有可以在深度和廣度上具有相當規(guī)模的Ja

54、vaScript程序的動態(tài)行為的研究。Ratanaworabhan等人已經(jīng)進行過和我們類似的研究，其最終結果也是和我們相似的。以前在javascript應用到安全領域時也確實有一些關于其動態(tài)行為的研究，但是那些研究只側重于和安全性緊密相關的部分。我們也曾進行過一些小規(guī)模的JavaScript研究，并得出了一些初步結果Harland，這些結果與這里提出的最新研究結果也是相吻合的。Holkner和也曾就Python語言動態(tài)特性的應用進行過研

55、究（添加和刪除作用域和方法），它們的研究重點集中在一系列小的程序上面，并得出了它們之間存在明確區(qū)別的結論。他們的研究表明，動態(tài)特性中的大部分都出現(xiàn)在程序的初始化階段，而在程序的主要運算階段，動態(tài)行為就逐漸減少了。我們的研究結果表明，在應用方面，JavaScript比Python更加動態(tài)化。關于面向對象語言在實時運行中的特性研究也有很多，比如Garret等人研究了Self語言中信息發(fā)送的動態(tài)程度，Calder等人則分析了C和C++程序運行

56、中的差異，Temporo等人研究了Java中</p><p>　　3、跟蹤和分析技術基礎</p><p>　　本文對基礎結構和跟蹤的研究是基于WebKit的網(wǎng)頁瀏覽器引擎的一個可以測量數(shù)據(jù)的版本，這個引擎現(xiàn)在被應用到了Apple的Safari瀏覽器上。雖然有可用的獨立解釋程序，他們卻無法處理目前在大部分支持JavaScript的網(wǎng)站常見的DOM和AJAX技術。為了提高實驗的靈活性，我們的分

57、析是在離線狀態(tài)下進行的。我們的瀏覽器記錄下由解釋程序帶來的大部分操作（讀，寫，刪除，調用，定義等），同樣作為垃圾收集和源文件加載的事件也會被跟蹤。Eval函數(shù)觸發(fā)一個特定事件的情形和源文件加載的情形是相似的，而經(jīng)過計算的字符串也將被保存，并像程序執(zhí)行時的其他部分一樣被追蹤分析。已經(jīng)追蹤到的痕跡被壓縮并存儲到磁盤中。雖然它在執(zhí)行時有一些額外的開銷，但是我們用來測試的工具在運行交互應用時的速度并沒有受到影響，并且我們的用戶也沒有對性能有任何

58、的抱怨。然后我們在離線狀態(tài)下分析了這些數(shù)據(jù)，并將結果存儲在一個數(shù)據(jù)庫中進行數(shù)據(jù)挖掘。離線痕跡分析組件實質上是對抽象流的解釋。它是能夠重現(xiàn)這些痕跡的，并為相應的JavaScript程序得出一個關于堆狀態(tài)的抽象解釋。痕跡分析儀中把包括了關于程序動態(tài)行為的豐富的和可定制的歷史信息，比</p><p><b>　　4、結論</b></p><p>　　本文提供了第一個大規(guī)模的