【正文】 rn typed languages. If deletion is an exceptional occurrence (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. system in the first place, 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 existing data flow analysis techniques. 4. The use of eval is infrequent and does not affect use of eval on arbitrary strings has the potential of invalidating any results obtained by static analysis or static type checking. Thus many works simply ignore it, while other 中原工學(xué)院信息商務(wù)學(xué)院畢業(yè)設(shè)計（論文）譯文專用紙 第 10頁 assume that uses are either trivial or related to deserialization using the JSON protocol . 5. Declared function signatures are indicative of 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 JavaScript allows calls with different arities. 6. Program size is modest. Some papers justify very expensive analyses with the explicit assumption that handwritten JavaScript programs are small, and others implicitly rely on this as they present analyses which would not scale to large systems. 7. Callsite dynamism is low. Some JavaScript implementations such as Google V8 rely on wellknown 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 JavaScript is broadly similar to that of other objectoriented languages 8. Execution time is dominated by hot loops. Tracebased Justintime pilers such as TraceMonkey rely on the traditional assumption that execution time is dominated by small loops. 9. Industry benchmarks are representative of JavaScript workloads. Standard enchmark suites such as SunSpider, Dromaeo and V8, are used to tune and pare 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 JavaScript workloads in the wild. 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 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 existing techniques and point to challenges that should be addressed in future research. Related Work. Until now, to the best of our knowledge, there has been no study 中原工學(xué)院信息商務(wù)學(xué)院畢業(yè)設(shè)計（論文）譯文專用紙 第 11頁 of the dynamic behavior of JavaScript programs of parable 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 dynamicbehavior as it applies to security, but the behaviors studied were restricted to those particularly relevant to conducted a small scale study of JavaScript and reported preliminary results in , and those results ar