如何JavaScript的主机对象实施？ [英] How are JavaScript host objects implemented?
问题描述
我在思考这个今天我意识到我没有一个清晰的图片浏览。
I was thinking about this today and I realized I don't have a clear picture here.
下面是一些声明，我认为是正确的（请纠正我，如果我错了）：
Here are some statements I think to be true (please correct me if I'm wrong):
- 的DOM是由W3C指定接口的集合。
- 解析HTML源代码code时，浏览器会创建具有实现DOM接口节点的DOM树。
- ECMAScript的规范有没有浏览器的主机对象（DOM，BOM，HTML5的API等）的参考。
- 的DOM实际上是如何实现依赖于浏览器内部，可能是不同的中间一大半。
- 现代JS间preters使用JIT提高code性能和它翻译成字节code
我很好奇在幕后发生的事情，当我打电话的document.getElementById（'富'）。是否调用get由各国preTER委托给浏览器的原生code还是浏览器拥有所有主机对象的JS实现？你知道他们对于这个做任何优化？
I am curious about what happens behind the scenes when I call document.getElementById('foo'). Does the call get delegated to browser native code by the interpreter or does the browser have JS implementations of all host objects? Do you know about any optimizations they do in regard to this?
我看了浏览器内部的这种概述，但没有提到这事。我期待通过当我有时间的Chrome和FF来源，但我想过问在这里第一次。 ：）
I read this overview of browser internals but it didn't mention anything about this. I will look through the Chrome and FF source when I have time, but I thought about asking here first. :)
推荐答案
您所有的要点是正确的，除了：
All of your bullet points are correct, except:
现代JS间preters使用JIT提高code性能和它翻译成字节code
modern JS interpreters use JIT to improve the code performance and translate it to bytecode
应该是......并将其转化为本地code。的SpiderMonkey（JS引擎在Firefox）担任字节code间preTER当前JS速度军备竞赛之前很长一段时间。
should be "...and translate it to native code". SpiderMonkey (the JS engine in Firefox) worked as a bytecode interpreter for a long time before the current JS speed arms race.
在Mozilla的JS到DOM桥：
On Mozilla's JS-to-DOM bridge:
主机对象通常用C ++实现，虽然有正在进行实现DOM在JS 。所以，当一个网页调用的document.getElementById（'富'），检索其ID的元素的实际工作是在C ++的方法进行，如hsivonen指出。
The host objects are typically implemented in C++, though there is an experiment underway to implement DOM in JS. So when a web page calls document.getElementById('foo'), the actual work of retrieving the element by its ID is done in a C++ method, as hsivonen noted.
底层C ++实现被调用的具体方式取决于API，也随着时间而改变（注意，我没有参与开发，因此可能是错误的一些细节，这里的博客文章由JST ，谁是实际参与创建这多少code的）：
The specific way the underlying C++ implementation gets called depends on the API and also changed over time (note that I'm not involved in the development, so might be wrong about some details, here's a blog post by jst, who was actually involved in creating much of this code):
- 在最低水平，每一个JS引擎提供的API定义主机对象。例如，浏览器可以调用JS_DefineFunctions（如 SpiderMonkey的用户指南证明），让发动机知道，每当脚本调用具有指定名称的功能，提供的C回调应该被调用。同为主机对象的其他方面（如枚举，财产getter / setter方法，等等。）
- 对于核心ECMAScript的功能，并在一些棘手的DOM情况下，JS引擎/浏览器中直接使用这些API定义主机对象和他们的行为，但它需要大量的通用样板code为例如中检查参数类型，将它们转换为相应的C ++类型，错误处理等。
- 对于原因，我不会进入，让我们在历史上说，Mozilla的大量使用
的getElementById，执行必要的参数检查/转换和路由呼叫直接到C ++方法（的nsDocument ::的getElementById（常量nsAString＆放大器;援助，nsIDOMElement ** aReturn）） - XPConnect工作方式是非常低效的：它注册通用函数作为当脚本访问一个宿主对象被执行回调，并且这些通用功能想出他们需要在每一个特定的情况下做动态的。 这篇文章关于quickstubs 引导您完成一个例子。
- 在previous链接提到的快速存根是一种方式来优化JS-> C ++通过交易它的一些code尺寸来电时间：不是一直使用通用的C ++知道如何做出任何功能一种叫，专门code会自动在Firefox中产生的建造时间为热呼叫pre定义的列表。
- 后来的JIT（的TraceMonkey当时）被教导要产生code调用作为本土code的一部分，在JS热路径生成的C ++方法。我不知道更新的即时编译器（的JaegerMonkey）如何在这方面的工作。
- 使用巴黎绑定对象的暴露与网页JS 不会对任何XPConnect依赖，而不是产生所有必需的胶水JSClass code基于WebIDL（而不是XPCOM时代IDL）。另见开发谁在这个岗位工作： JST 和 khuey 。另请参阅<一个href=\"https://ask.mozilla.org/question/390/how-is-the-web-exposed-dom-implemented/?answer=391#post-id-391\"相对=nofollow>网络曝光DOM是如何实现的？
- At the lowest level every JS engine provides APIs to define host objects. For example, the browser can call JS_DefineFunctions (as demonstrated in the SpiderMonkey User Guide) to let the engine know that whenever script calls a function with the specified name, a provided C callback should be called. Same for other aspects of the host objects (e.g. enumeration, property getters/setters, etc.)
- For the core ECMAScript functionality and in some tricky DOM cases the JS engine/the browser uses these APIs directly to define host objects and their behaviors, but it requires a lot of common boilerplate code for e.g. checking parameter types, converting them to the appropriate C++ types, error handling etc.
- For reasons I won't go into, let's say historically, Mozilla made heavy use of XPCOM for many of its objects, including much of the DOM. One feature of XPCOM is its binding to JS called XPConnect. Among other things, XPConnect can take an interface definition in IDL (such as nsIDOMDocument; or more precisely its compiled representation), expose an object with the specified properties to the script, and later, when a script calls
getElementById, perform the necessary parameter checks/conversions and route the call directly to a C++ method (nsDocument::GetElementById(const nsAString& aId, nsIDOMElement** aReturn)) - The way XPConnect worked was quite inefficient: it registered generic functions as callbacks to be executed when a script accesses a host object, and these generic functions figured out what they needed to do in every particular case dynamically. This post about quickstubs walks you through one example.
- "Quick stubs" mentioned in the previous link is a way to optimize JS->C++ calls time by trading some code size for it: instead of always using generic C++ functions that know how to make any kind of call, the specialized code is automatically generated at the Firefox build time for a pre-defined list of "hot" calls.
- Later on the JIT (tracemonkey at that time) was taught to generate the code calling C++ methods as part of the native code generated for "hot" paths in JS. I'm not sure how the newer JITs (jaegermonkey) work in this regard.
- With "paris bindings" the objects are exposed to webpage JS without any reliance on XPConnect, instead generating all the necessary glue JSClass code based on WebIDL (instead of XPCOM-era IDL). See also posts by developers who worked on this: jst and khuey. Also see How is the web-exposed DOM implemented?
我在，特别是最后三个点的细节模糊，所以把它当作一粒盐。
I'm fuzzy on details of the three last points in particular, so take it with a grain of salt.
最近的改进被列为的bug 622298 的依赖关系，但我不按照他们密切。
The most recent improvements are listed as dependencies of bug 622298, but I don't follow them closely.
这篇关于如何JavaScript的主机对象实施？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
