Sort of a mangled transcript of the embedding meeting at the 2014 Toronto JS work week.
Users - AMO for linting etc. - Gecko - GNOME Shell - MongoDB was, but switched to V8 If you want to validate against Spidermonkey, you kind of need to use Spidermonkey. Or heuristics. till: can we keep on doing what we doing now, no API stability, no cohesive design in the API. Or whould we see that now that exact rooting is done, can we clean up JSAPI? And add stability guarantees. Would we want to meaningfully change the API to push for cohesiveness? Personally, I think there are good reasons for doing that. Downsides: costs to do it in the 1st place. Stability guarantees would slow down some stuff we're doing for Gecko. Can all the other embeddings just play 2nd fiddle to Gecko? mjrosenberg: Are we planning on doing anything in the future that would break the PAI? Waldo: we never plan it. We sort of know about some things we want to remove, but haven't had a good enough reason yet. mjrosenberg: all the GC changes broke it. Switch from C -> C++. Compartment per global. Removing threading. Ripping out the File API. Waldo: CPG didn't really break it, but Gecko is really whacked about how it uses compartments. If you're not being that crazy. Threading was always kind of broken, and no one offers that. ctypes is a little weirdo. till: I sat down with the de facto maintainer of ctypes, David Teller. He was really interested in reimplementing it on top of typed objects. jdm: the big thing that affected Servo was the removal of finalizers on proxy objects. Waldo: there used to be only 2ish proxy classes. efaust made it so anything can be one. So you should be able to use finalizers again. jdm: we are using version from Nov 2012, largely because of the C API. Looking at compiling spidermonkey to llvm code, and talking to that directly via servo. mjrosenberg: are you going to use spidermonkey's GC for everything, or have 2? jdm: Rust will have a GC, but we don't plan to use it, especially not for anything in the DOM. Currently, DOM's lifetime is dependent entirely on SM's GC. mjrosenberg: what do embedders do in general? Mnaage all the memory, or let SM do it, or combo? Waldo: could probably guess. Don't put their malloced memory into objects and free with finalizers. mjrosenberg: Gnome shell overrides our allocate with glib's allocator. Waldo: which we support till: do we have any projects on the horizon that would force us to make large changes to the API? sfink: Like cx removal? Waldo: yeah, that. We won't know until we try it how that'll work out. jdm: timeframe? Waldo: probably not in a 6mo-1yr. jdm: helps decide when to upgrade. Waldo: probably not the biggest pain point. till: could we create a stable core API, ignoring cx removal? Waldo: jsid -> PropertyKey (string or symbol in ES6). Ours will hold everything. Under that will be ElementPropertyKey and IndexedPropertyKey. Under that will be symbol or value. Ideally, we'll be able to call with the specific one. Will probably have coexistence for a while. jsid is sort of what we want, but not the right split. Lars: what advantage does spidemronkey give? - asm.js - support/IRC - at least formerly, spidermonkey had advanced features What does servo use? - runtime per toplevel domain - global/compartment per tab/iframe - DOM binding stuff (use WebIDL) - no Xrays or other wrappers Trying to avoid having chrome code at all. Have a branch where we have fused DOM/JS objects, using Rust's shiny new placement new. Have fairly large usage of friend API because DOM bindings use it. For the DOM bindings, servo search/replaces python code for generating the bindings to switch from C++ -> Rust. Other embeddings may want to have DOM binding equivalents. mjrosenberg: WOuld be nice to find out what embedders are using. till: reasons to provide stability - although V8 team is unapproachable, they get good contributions from people using their embedding. Most famous is NodeJS. - Chrome as a browser gets a lot of devleoper mindshare via NodeJS via embedding V8. It is possible that it is something we could get as well. Waldo: kind of did the same thing when Webkit showed up. We dropped Gecko embedding. Now on mobile Webkit is all there is. The fact that there is a decent alternative is a big deal. Now we've circled back and created GeckoView. Not used much yet. GNOME's browser switched from Gecko to Webkit a few years ago. The gnome devs were very happy with the change because our embedding sucked. till: boldest version is to recreate something like Spidernode and promote it as NodeJS with asm.js and more support for newer language features. asm.js seems to be a good answer to quite a few things that nodejs does. NodeJS has a strength in being easily extensible by native modules, but it sucks in shared hosting environments, because the native stuff has to be trusted by whoever runs the server. Used because reimplementing in JS would be too slow or too much work. Both are addressed by asm.js, and would be persuasive to get members of the NodeJS community to switch to our version. Would be boldest and most resource intensive. Would require not only making a nice API, but would have to match V8's API. Lars: I assume that the most popular NodeJS extensions are syscall-heavy. What's asm.js's answer? till: One I hear frequently is image processing. Or DB stuff. But yes, quite a few do use system stuff. Lars: but asm.js has an ffi? Waldo: yes mjrosenberg: to JS. Waldo: if you provide it with a fucntion that does the C stuff, it can do that. till: if integrated with typed objects, it would be nice. Marty mentioned yesterday that game engines almost always integrate some scripting language. If that were spidermonkey, then in a modified version of emscripten, we could directly use a browser's host JS. mjrosenberg: I got a basic HelloWorld to work, but lost the changes. I wonder if something similar could be used for NodeJS/Spidermonkey. till: I think you can debug NodeJS with the Chrome debugger, though it isn't ideal. Next steps: - propose a good new API? Even if it's v8's? - look at Servo and other existing embeddings to extract out the core API we need - look at V8 embeddings and look at what they use - jdm knows someone interested in V8 embeddings. Can ask him what he uses, and what he thinks an API should provide. He says he'd like an abstraction layer to Servo so he could try replacing spidermonkey with v8. - till will draft a justification document sfink: How much would we gain by jettisoning any pretense of embedder support? Waldo: not much. We only remove APIs when we have a specific reason to. We generally leave stuff lying around if it isn't getting in the way. Lars: If we could be a showcase for tech that we have and nobody else has, it would be worth something. till: seeing how excited people were at GDC... nothing has given us anywhere near as much credibility as that for our technology Lars: but that's for running in a browser, so it's really for Gecko embedding, not Spidermonkey. till: the integration of frontend and backend is potentially very interesting. To not only use spidermonkey for the browser but also the backend. I don't know how interesting that is to people. Except people really like fast server-side environments. But for many cases on the server side, you just run C++ code. Lars: if you were really interested in security, it would be good to use JS instead of C++. till: we seem to be perceived as the engine implementing the newest JS features. Waldo: someone was complaining that V8 has Object.observe implemented and it made some AngularJS application way way faster. We might want to be conservative in assuming that we're ahead on various ES6 things. till: I've heard it a number of times, and even if it's not clear cut, should we try to be perceived that way? Waldo: I think it's a reasonable thing. till: I'm absolutely convinced it's a big deal. evilpie: V8 implemented a lot of stuff that's really hard for us. Object.observe, symbols. CouchDB uses spidermonkey. MongoDB switched from Spidermonkey -> V8 a few releases ago. Couldn't find anything on Postgres. evilpie: symbols are interesting even for API design, because it changes the id API. _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
