info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Raw notes from meeting on Spidermonkey embedding
110 views
Skip to first unread message
Steve Fink
Mar 25, 2014, 4:41:30 PM3/25/14
to js-internals
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.
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.
David Bruant
Mar 25, 2014, 6:21:11 PM3/25/14
to Steve Fink, js-internals
Le 25/03/2014 21:41, Steve Fink a écrit :
> Sort of a mangled transcript of the embedding meeting at the 2014
> Toronto JS work week.
>
> Users
> - AMO for linting etc.
This might be better served by eslint moving forward
> Sort of a mangled transcript of the embedding meeting at the 2014
> Toronto JS work week.
>
> Users
> - AMO for linting etc.
https://github.com/eslint/eslint/
> - 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.
> Lars: what advantage does spidemronkey give?
> - asm.js
> - support/IRC
> - at least formerly, spidermonkey had advanced features
I think the debugger API is full of potential and seriously underused.
> 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.
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).
> 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.
(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.
> 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.
https://bugzilla.mozilla.org/show_bug.cgi?id=800355#c5
From what I know, Object.observe makes bad (in the sense of "not
following AngularJS assumptions for good performance" [1]) 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)
> 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.
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)
David
[1] Interesting talk on the topic http://www.youtube.com/watch?v=mVjpwia1YN4
Till Schneidereit
Mar 25, 2014, 6:48:00 PM3/25/14
to David Bruant, Steve Fink, js-internals
On Tue, Mar 25, 2014 at 6:21 PM, David Bruant <brua...@gmail.com> wrote:
> Le 25/03/2014 21:41, Steve Fink a écrit :
>
> Sort of a mangled transcript of the embedding meeting at the 2014
>> Toronto JS work week.
>>
>> Users
>> - AMO for linting etc.
>>
> This might be better served by eslint moving forward
> https://github.com/eslint/eslint/
No, it wouldn't, unfortunately: this is for Gecko app addons, so it has to
> Le 25/03/2014 21:41, Steve Fink a écrit :
>
> Sort of a mangled transcript of the embedding meeting at the 2014
>> Toronto JS work week.
>>
>> Users
>> - AMO for linting etc.
>>
> This might be better served by eslint moving forward
> https://github.com/eslint/eslint/
take all the slight weirdness into account that our implementation of the
language supports.
>
>
> - 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.
>>
> To validate what?
isn't a planned project, btw: it's in active use right now.
>
>
> Lars: what advantage does spidemronkey give?
>> - asm.js
>> - support/IRC
>> - at least formerly, spidermonkey had advanced features
>>
> Debugger API. Upcoming memory introspection features.
> I think the debugger API is full of potential and seriously underused.
>
>
> 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.
>>
> 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).
much weight.
perf analysis tools that'll be implemented using the debug API as their
transport. So apps could just be debugged using the Firefox devtools.
>
>
> till: we seem to be perceived as the engine implementing the newest JS
>> features.
>>
> On par with V8 from what I hear (just different features).
timeframe that's of interest for the topic at hand.
>
>
> 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.
>>
> Hmm... A fanboi for sure...
> https://bugzilla.mozilla.org/show_bug.cgi?id=800355#c5
> From what I know, Object.observe makes bad (in the sense of "not following
> AngularJS assumptions for good performance" [1]) 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)
however, have any knowledge about how it is prioritized.
>
>
> 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.
>>
> 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)
>
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.
>
> David
>
Bobby Holley
Mar 28, 2014, 5:20:10 PM3/28/14
to Till Schneidereit, Steve Fink, David Bruant, js-internals
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.
bholley
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>
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.
bholley
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>
0 new messages