|Raw notes from meeting on Spidermonkey embedding||Steve Fink||3/25/14 1:41 PM|
Sort of a mangled transcript of the embedding meeting at the 2014
Toronto JS work week.
- AMO for linting etc.
- 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
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
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.
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?
- 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
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
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
- 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
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
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.
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.
|Re: Raw notes from meeting on Spidermonkey embedding||David Bruant||3/25/14 3:21 PM|
Le 25/03/2014 21:41, Steve Fink a écrit :This might be better served by eslint moving forward
To validate what?
Debugger API. Upcoming memory introspection features.
I think the debugger API is full of potential and seriously underused.
How common a use case is it?
It's never been a problem for me or the people I know who use Node.js
(admittedly a small subset).
I think V8 has been catching up on asm.js-like code, so it's already
possible to use asm.js on Node today with decent performance (to solve
the shared hosting environment trust issue).
Debugging is clearly an area where everyone agrees Node sucks
(especially because the stack trace is small and contains only the last
callback call which is rarely enough context to understand where an
error is from). Though I haven't looked at whether the situation will be
improving in Node 0.12.
SpiderNode has no value for itself (and asm.js isn't enough to convince
me at least). However, with the Debugger API, you give JS devs an
opportunity to solve the problem by themselves (where the V8 debugging
API seems too high barrier). I'm sure lots of people would use
SpiderNode if it promised a better debugging story.
On par with V8 from what I hear (just different features).
Hmm... A fanboi for sure...
From what I know, Object.observe makes bad (in the sense of "not
following AngularJS assumptions for good performance" ) AngularJS
applications way way faster. It's unclear if the impact on performance
is otherwise that significant.
In any event, Object.observe really is an expected feature (44 cc's on
the bug with no technical progress certainly is an indication of something)
At which cost, though? Proxy.create is still around and I have stopped
counting the number of blog posts, gist, tweets where I've had to tell
people they were using an outdated API. The only reason ES6 hasn't
failed is because V8 keeps pretty much everything new behind a flag.
Not having feature flags on SpiderMonkey is an eventual problem. Might
become a very serious problem with FirefoxOS as some may venture to rely
on SpiderMonkey-specific features for the sake of being smart (whaddup
Object.prototype.watch and __noSuchMethod__ ! ... and '@@iterator' if
someone finds that)
 Interesting talk on the topic http://www.youtube.com/watch?v=mVjpwia1YN4
|Re: Raw notes from meeting on Spidermonkey embedding||Till Schneidereit||3/25/14 3:48 PM|
On Tue, Mar 25, 2014 at 6:21 PM, David Bruant <brua...@gmail.com> wrote:No, it wouldn't, unfortunately: this is for Gecko app addons, so it has to
take all the slight weirdness into account that our implementation of the
See above, addons. That's why we can only really use SpiderMonkey. This
isn't a planned project, btw: it's in active use right now.
Agreed, and we talked about this.
It's an open question, but yes: this argument isn't likely to carry too
We'd essentially get that for free, including the forthcoming memory and
perf analysis tools that'll be implemented using the debug API as their
transport. So apps could just be debugged using the Firefox devtools.
The real question is where we can and want to be on that front in a
timeframe that's of interest for the topic at hand.
Object.observe is pretty awesome, IMO: I really like data binding. I don't,
however, have any knowledge about how it is prioritized.
We've essentially adopted a very similar approach: features that're not
fully baked are only available in Nightly and Aurora. For ES6 that's not
really an issue anymore at this point.
Also, "the only reason ES6 hasn't failed"? Bold words.
|Re: Raw notes from meeting on Spidermonkey embedding||Bobby Holley||3/28/14 2:20 PM|
Just to chime in my high-level 2-cents as someone who wasn't there. I don't
think SM is ready for a stable API. There are a lot of big embedder-facing
changes that I'm making, including:
* Fundamentally altering error reporting semantics ( bug 981187 and friends
* Removing default compartment objects ( bug 981218 )
* Removing saved frame chains (bug 979730 )
* Removing the Request API ( bug 722345 )
* Removing JSContexts ( bug 650361 )
Give it a year, and then let's have this discussion again.
> dev-tech-js-engine-internals mailing list