Threads and GC API changes
Jason Orendorff
SpiderMonkey's threading model and garbage collector. These changes
will affect embeddings that are sharing objects among threads.
Details and rationale here:
https://wiki.mozilla.org/JSThreadsAndGC
I'm announcing this in advance of having the new proposed API in
hand. You can expect a rough proposal later this week. Questions and
comments are welcome, as always.
-j
John J Barton
Of course I would like to know what this means:
---
I don't think enough is known about the new debugger's eventual
design. By mid-March 2010 we'll know more.
---
jjb
>
> -j
>
Jason Orendorff
> Of course I would like to know what this means:
>
> ---
> I don't think enough is known about the new debugger's eventual design.
> By mid-March 2010 we'll know more.
> ---
Jim Blandy plans to spend some time in March on debugger infrastructure.
Whether we will actually end up with a "new debugger" (by which I mean a
replacement for JSD, *not* a replacement for Firebug) I don't know. One
of Jim's goals will be to support cross-thread and cross-process
debugging. Apart from that, not much is decided. We haven't even
reviewed what exactly JSD exposes yet, much less what sort of debugging
features other browsers have.
Would you like to join the early IRC conversations about this? They
aren't exactly scheduled, but we can ping you on IRC or something. It's
going to be a week or two before that effort really spins up.
-j
johnjbarton
> On 03/01/2010 07:24 PM, John J Barton wrote:
>> Of course I would like to know what this means:
>>
>> ---
>> I don't think enough is known about the new debugger's eventual design.
>> By mid-March 2010 we'll know more.
>> ---
>
> Jim Blandy plans to spend some time in March on debugger infrastructure.
>
> Whether we will actually end up with a "new debugger" (by which I mean a
> replacement for JSD, *not* a replacement for Firebug) I don't know. One
Well we certainly need to work on some things in the jsd space.
> of Jim's goals will be to support cross-thread and cross-process
Absent any activity on the core side, we have been working on
cross-thread and cross-process debugging for many months now.
Mike Collins has developed a Javascript remote debug protocol roughly
similar to a superset of the V8 protocol for Javascript and similar in
other abilities to Dragonfly's Scope protocol (Opera). He is working to
allow it to support IDE <-> Firebug-like out of process debugger as well
as Firebug remote UI <-> Firefox debug core. More information:
http://groups.google.com/group/webdebugprotocol?hl=en
Our next step, planned for Firebug 1.7, is to split the Firebug into UI
(mainly Firebug 'panels') and core (mainly Firebug 'modules'). The UI
layer will merge with Pedro Simonetti's work on Firebug Lite to improve
our developers/lines of code. The core layer will live in a server in
the browser.
Referring back to the topic here, I expect that running a new instance
of a jsd-like component in each of your 'regions' and layering the
Firebug Core server on that will be effective. The same approach will
work for multiprocess obviously.
> debugging. Apart from that, not much is decided. We haven't even
> reviewed what exactly JSD exposes yet, much less what sort of debugging
> features other browsers have.
The other browsers have concentrated on catching up with Firebug. They
are closing in; we are just beginning to hear reports of "why don't you
have X like Y". Based on feedback I hear, when V8 completely integrates
with Web Inspector (Webkit version of DOM Inspector) a significant
number of Firefox-based developers will move to Chrome. I'd love to
compete with them by innovations they have to imitate.
In thinking about debugging one has to get beyond javascript. Firebug is
a "web debugger", not a "javascript debugger": that is why it became the
leader. Ironically many of the innovations in the non-js part of Firebug
make the js debugger look lame. We should fix that.
> Would you like to join the early IRC conversations about this? They
> aren't exactly scheduled, but we can ping you on IRC or something. It's
> going to be a week or two before that effort really spins up.
I only use IRC when I'm really desperate so you'd have to pick a time.
See also
[jsd] Modernize jsdIDebuggerService: jsd2
https://bugzilla.mozilla.org/show_bug.cgi?id=449452
Make Mozilla Error Messages Better
https://bugzilla.mozilla.org/show_bug.cgi?id=435025
Firebug 1.7: Architecture Refactoring
http://getfirebug.com/wiki/index.php/Firebug_1.7:_Architecture_Refactoring
jjb
Jim Blandy
>I'd love to
> compete with them by innovations they have to imitate.
>
> In thinking about debugging one has to get beyond javascript. Firebug is
> a "web debugger", not a "javascript debugger": that is why it became the
> leader. Ironically many of the innovations in the non-js part of Firebug
> make the js debugger look lame. We should fix that.
I'm still coming up to speed on all this, but we certainly want to end
up with something that makes advancing firebug's JS support easier.
Thanks for the references; I'll check them out.
Brendan Eich
[Sorry if this goes over old ground. I wanted to dump some thoughts
already shared with Jason via IRC on the group. /be]
I've been arguing that we need to keep three things working as we
develop, as usual:
1. Web workers and anything like them, which currently rely on
JS_THREADSAFE and the request model.
2. Pure-JS XPConnect-based cross-thread JS by our own add-ons and XUL
apps. 126 source files hosted at addons.mozilla.org use nsIThread,
e.g.
3. Embeddings that use JS_THREADSAFE well, meaning they can say which
objects are multi-thread accessible.
Category 1 needs to be kept working somehow. To avoid a JSRuntime per
worker, we can use the same context group or isolated heap that the
wiki'd Plan proposes.
But workers use XPConnect too, so they're in category 2. And with
structured cloning optimizations (http://www.whatwg.org/specs/web-apps/
current-work/#internal-structured-cloning-algorithm) they may want to
share copy-on-write or frozen objects cross-heap, again raising the
issue of cross-thread proxies.
Category 2 is not to be dismissed lightly. Apart from debuggers, it
includes more than a hundred addons. This is one part of the wiki'd
Plan that I do not find credible, never mind optimal.
There is no boil-the-oceans plan to change addons' programming model.
Addon compat does change from Firefox release to release, but often
it's just a matter of testing and certifying max-version. Removing
cross-thread XPCOM scripting outright, "suggesting" message passing or
some not-yet-invented solution, is a non-starter. To integrate, test,
land, and get into nightlies we need to preserve nsIThread, etc.
scripting.
Category 3 will face JS API changes, some wanted since the API is hard
to use and optimize (e.g., double jsvals, exact GC rooting). I have
been advocating a change whereby all objects created by existing API
calls/parameters are single-threaded. Multi-threaded embeddings
needing MT-accessible objects will have to use new API to create MT-
accessible objects and other GC-things. But as with category 2, notice
that this is a C/C++ API change only -- the JS scripts do not see
compatibility breakage.
The goal should be elimination of JS_THREADSAFE, while preserving
thread safety for those objects distinguished at birth by being
created by the new API.
One way to do this with full generality, as the wiki'd Plan mentions,
is for the thread-safe objects would be wrappers or proxies to
underlying ST objects created by existing APIs.
It so happens we have been working on JSObjectOps (see
https://bugzilla.mozilla.org/show_bug.cgi?id=408416), specifically in
the context of ECMAScript "Harmony" proxies (see
http://wiki.ecmascript.org/doku.php?id=harmony:proxies and the bug
where Andreas Gal has implemented this spec:
https://bugzilla.mozilla.org/show_bug.cgi?id=546590), and we'll
continue to improve JSObjectOps to allow fully transparent wrappers or
proxies. The security wrappers in Mozilla are moving to JSObjectOps
rather than JSClass, too, and for the same reasons: to be fully
transparent and mediate all accesses.
Given thread-safe wrappers, it seems that all three categories:
* workers if they need them, e.g. for postMessage structured cloning;
* XPConnect for add-ons, plugins, apps, debuggers, and of course
workers; and
* JS_THREADSAFE SpiderMonkey embeddings
can create the set of objects they need to publish cross-thread, wrap
them, and then proceed to interact with them. This is the basis case.
As we do with native-object and security wrappers, the thread-safe
wrappers transitively wrap any unwrapped dependent property values,
parameters, and results flowing through the already-wrapped objects.
This is the induction step.
Is there a native back door by which an unsafe object could be passed
cross-thread? Perhaps, but that seems like a bug, or possibly a second
inductive step we will have to monitor with a wrapping barrier.
This way, the penalty for thread-safe operation accrues only in the
wrapper's JSObjectOps implementations, which are atomic. There may be
re-entry issues here, but for this application we can tolerate them
(as Java does, or did when I was paying attention to it). We want to
avoid nesting distinct object locks, to avoid deadlock (assuming we
can't contrive an ordering protocol; but nesting is bad in any case).
I'm posting this, at the risk of rehashing the wiki'ed Plan, to try to
persuade interested partites that JS_THREADSAFE must die but thread-
safety should not, in any patch series we can land and ship in a
foreseeable Firefox release.
Indeed I believe cross-thread wrappers or proxies are the shortest
path to getting the GC heap in our one JSRuntime split up into thread-
local and indeed window clique local heaps, while keeping all
categories of consumers working (the embedders with some added API
obligations).
There could be trouble with locking wrapper reentry or nesting. We
should think this through and possibly work it through. But I do not
find it credible, never mind JS_THREADSAFE embeddings, just
considering Firefox, that we would break all cross-thread JS access,
specifically XPConnect-mediated access where no C or C++ API usage is
involved or required (those 126 addons.mozilla.org hits for nsIThread,
and others).
Comments welcome.
/be
Boris Zbarsky
> 2. Pure-JS XPConnect-based cross-thread JS by our own add-ons and XUL
> apps. 126 source files hosted at addons.mozilla.org use nsIThread,
> e.g.
A number of these are not actually using it, just mentioning it
(comments, dead code, etc).
That said, I looked at the first few hits;
https://mxr.mozilla.org/addons/search?string=nsIThread&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=addons
for those with the bits. About 20-30% of the actual consumers I see are
using it wrong (touching Windows from off the main thread, which will
likely leak and if you're unlucky deadlock or crash). About 30% of the
extensions I looked at that came up in the search weren't actually using it.
> Category 2 is not to be dismissed lightly. Apart from debuggers, it
> includes more than a hundred addons. This is one part of the wiki'd
> Plan that I do not find credible, never mind optimal.
See above.
> There is no boil-the-oceans plan to change addons' programming model.
Really? It seemed to me that was exactly what shaver and I were talking
about...
The current threading model for addons is _hard_ and hard in ways that
are non-obvious. It's very difficult to tell whether your code using
nsIThread is safe unless you happen to know exactly which global object
it will run against, for example. That happens to be a non-local property.
> Addon compat does change from Firefox release to release, but often
> it's just a matter of testing and certifying max-version. Removing
> cross-thread XPCOM scripting outright, "suggesting" message passing or
> some not-yet-invented solution, is a non-starter. To integrate, test,
> land, and get into nightlies we need to preserve nsIThread, etc.
> scripting.
It seems to me like the order would have to be:
1) Create working message passing API.
2) Make nsIThread noscript.
3) Make whatever changes couldn't handle scriptable nsIThread.
if we decide to get rid of scriptable nsIThread.
> The goal should be elimination of JS_THREADSAFE, while preserving
> thread safety for those objects distinguished at birth by being
> created by the new API.
How does that play with your suggestions of source-compat for
nsIThread-using addons?
> One way to do this with full generality, as the wiki'd Plan mentions,
> is for the thread-safe objects would be wrappers or proxies to
> underlying ST objects created by existing APIs.
I'm not sure how that case will help the situation where an addon wants
to run some code on the non-main thread. It has to create the Function
to run on the main thread (that's where it's already running). Then
what happens?
> * workers if they need them, e.g. for postMessage structured cloning;
> * XPConnect for add-ons, plugins, apps, debuggers, and of course
> workers; and
> * JS_THREADSAFE SpiderMonkey embeddings
>
> can create the set of objects they need to publish cross-thread, wrap
> them, and then proceed to interact with them. This is the basis case.
I may be being dense, but I'd still like to understand how the add-on
xpconnect thing works here.
I assume you're familiar with the nsIThread api? Basically, you pass a
function (or an object with a function-valued "run" property, which is
really the same thing) to nsIThread and it then invokes that function on
the other thread. The function is nullary. If it has any data it works
with, it must close over that data. What proxies/wrappers will this
setup create, and how will it fulfill the goal of running stuff on a
background thread without interfering with the main thread's execution
in any way?
-Boris
Mike Moening
> objects are multi-thread accessible.
That would be fine by me... By objects I assume you mean global object
and/or any object or property living in that global.
One purpose of sharing a global between threads is to get the same set of
standard classes (to solve InstanceOf() breakage)
and as a way of sharing simple objects.
For example: Think javascript based web server.
A "session" can be created on the server. That session roughly corresponds
to a "session global" JSObject.
Which contains properties and objects that need to be shared by all incoming
we server requests for that session.
The session global is the lowest level in the chain.
Each request also has a global which is chained via prototype back to the
session global (assuming the request is is part of a session).
That global is temporary and can be destroyed after the request ends.
The chaining is done so that standard classes can be initialized once and
saved in the session. Also solves InstanceOf() problems..
If we had a way of telling JS at creation time that the session global needs
to be "thread safe" we would be in good shape.
Also this pattern needs to be supported by JIT without blacklisting.
Lastly some kind of thread local GC or thread local free lists would be nice
to save on contention in heavy threading.
In other words don't make thread A suffer just because thread B triggered
GC.
An also don't let thread B take away free things from thread A (which might
need them later).
Some sort of shared memory pool might be necessary for those objects that
are marked as "thread safe". But that should be the exception not the rule.
Brendan Eich
> On 3/2/10 10:21 PM, Brendan Eich wrote:
>
> > 2. Pure-JS XPConnect-based cross-thread JS by our own add-ons and XUL
> > apps. 126 source files hosted at addons.mozilla.org use nsIThread,
> > e.g.
>
> A number of these are not actually using it, just mentioning it
> (comments, dead code, etc).
>
> for those with the bits. About 20-30% of the actual consumers I see are
> using it wrong (touching Windows from off the main thread, which will
> likely leak and if you're unlucky deadlock or crash). About 30% of the
> extensions I looked at that came up in the search weren't actually using it.
Using it wrong is one thing -- people use Windows APIs and (from
drivers or modules) even kernel internals wrong and if their code
survives the process and becomes popular, it may even need to be
supported, or at least not summarily broken at a certain release date.
30% not actually using it helps prorate the hit on nsIThread. Say only
a third of the hits are good uses. 42 is still a significant number
(not just in THHGttG ;-).
There's more to consider than this one a.m.o query. See also:
http://www.google.com/codesearch?q=lang%3Ajavascript+nsIThread&hl=en&btnG=Search+Code
> > There is no boil-the-oceans plan to change addons' programming model.
>
> Really? It seemed to me that was exactly what shaver and I were talking
> about...
Yeah, but I don't think you can pull it off -- not as described. You
shouldn't want to try, anyway, since the downside risk is larger than
the risks people take today using XPConnect cross-thread.
> The current threading model for addons is _hard_ and hard in ways that
> are non-obvious. It's very difficult to tell whether your code using
> nsIThread is safe unless you happen to know exactly which global object
> it will run against, for example. That happens to be a non-local property.
Yes, this needs to be fixed, with better APIs brought up before old
ones go away -- see Raymond Chen's "old new thing" blog.
> It seems to me like the order would have to be:
>
> 1) Create working message passing API.
> 2) Make nsIThread noscript.
> 3) Make whatever changes couldn't handle scriptable nsIThread.
>
> if we decide to get rid of scriptable nsIThread.
Who does 3, when in relation to the release date that includes 2?
I think whatever we do, we shouldn't break old APIs before better new
ones are actually designed, implemented, stabilized, and documented.
We have an opportunity to migrate addons developers to better APIs.
These may well involve message passing (I'm a fan) but they could also
use cross-thread wrappers or proxies in order to preserve
compatibility and simplicity compared to the rewrite tax and inherent
message-passing serialization overhead and restrictions.
It's not at all clear to me we should jump on message-passing and
throw JS object sharing cross-thread, given the trade-offs.
> > The goal should be elimination of JS_THREADSAFE, while preserving
> > thread safety for those objects distinguished at birth by being
> > created by the new API.
>
> How does that play with your suggestions of source-compat for
> nsIThread-using addons?
Nick Nguyen may have data on how many addons at a.m.o have binary
components, but they are few and far between. My concern with Category
2 was about, as noted above, "[p]ure-JS XPConnect-based cross-thread
JS ..." in apps as well as addons.
> > One way to do this with full generality, as the wiki'd Plan mentions,
> > is for the thread-safe objects would be wrappers or proxies to
> > underlying ST objects created by existing APIs.
>
> I'm not sure how that case will help the situation where an addon wants
> to run some code on the non-main thread. It has to create the Function
> to run on the main thread (that's where it's already running). Then
> what happens?
The nsIRunnable-implementing JS object would be wrapped automatically,
for the wrapper proposal to maintain nsIThread-related source
compatibility. This would have to happen in xpcom/threads code, using
new JS API.
The nsIRunnable object, its run function, and other things entrained
in the environment of the run function must "become" their wrappers
(Smalltalk become, change of internals without change of identity),
for this scheme to uphold thread safety even on the main thread. This
is something Andreas's proxies can do. We're talking about
generalizing it.
> I assume you're familiar with the nsIThread api? Basically, you pass a
> function (or an object with a function-valued "run" property, which is
> really the same thing)
Sure, nsIRunnable. I remember :-P.
> to nsIThread and it then invokes that function on the other thread.
Yeah, nsIEventTarget::dispatch.
> The function is nullary. If it has any data it works
> with, it must close over that data.
Right! Notice for example:
https://mxr.mozilla.org/addons/source/4891/chrome/common/content/liberator.js
which has this prototype-based generic run function:
32 run: function () { this.func.apply(this.self,
this.args); }
and later:
1901 callInMainThread: function (callback, self)
1902 {
1903 let mainThread =
services.get("threadManager").mainThread;
1904 if (!services.get("threadManager").isMainThread)
1905 mainThread.dispatch({ run: callback.call(self) },
mainThread.DISPATCH_NORMAL);
1906 else
1907 callback.call(self);
1908 },
> What proxies/wrappers will this
> setup create, and how will it fulfill the goal of running stuff on a
> background thread without interfering with the main thread's execution
> in any way?
Consider what happens today: we have pervasive ownercx-testing/
js_LockObj/js_LockScope/js_{Get,Set}SlotThreadsafe costs to ensure
thread safety in the JS engine for all native objects.
We want these costs moved down into the wrapper JSObjectOps
implementation, leaving native objects truly lock-free and single-
threaded/thread-unsafe.
The transitive wrapping and "becomes" magic follow from this goal, and
unlike today, they take their tolls only to the degree cross-thread
objects are actually used, and without hurting unrelated native object
performance. Their source and runtime complexity is confined to the
wrapper's non-native JSObjectOps implementation.
I'll stop here and wait for questions. I'm sure you have more (I do
too ;-).
/be
Boris Zbarsky
> Using it wrong is one thing -- people use Windows APIs and (from
> drivers or modules) even kernel internals wrong and if their code
> survives the process and becomes popular, it may even need to be
> supported, or at least not summarily broken at a certain release date.
OK... but see below.
> Yeah, but I don't think you can pull it off -- not as described. You
> shouldn't want to try, anyway, since the downside risk is larger than
> the risks people take today using XPConnect cross-thread.
The risk people take now is that it's easy to produce
crashes/hangs/leaks without the extension author realizing it and
without the user realizing that the extension is causing these problems.
So for _us_ the downside risk of the current extension threading model
is huge, as far as I can see. That risk being random
crashes/hangs/leaks the user will blame on us.
> Yes, this needs to be fixed, with better APIs brought up before old
> ones go away
Well, sure.
>> 1) Create working message passing API.
>> 2) Make nsIThread noscript.
>> 3) Make whatever changes couldn't handle scriptable nsIThread.
>>
>> if we decide to get rid of scriptable nsIThread.
>
> Who does 3, when in relation to the release date that includes 2?
Did you mean 2 and 1 respectively?
3 and 2 could happen in the same release. You could make the case that
there should be a release that contains 1 but hasn't had 2 happen yet to
allow migration, I guess. I personally would be ok with those happening
in the same release as well as long as we do 1 early enough that we ship
it in betas and extensions can adapt. That's about how we landed
nsIThread instead of the previous threading setup!
> I think whatever we do, we shouldn't break old APIs before better new
> ones are actually designed, implemented, stabilized, and documented.
Sure.
> We have an opportunity to migrate addons developers to better APIs.
> These may well involve message passing (I'm a fan) but they could also
> use cross-thread wrappers or proxies in order to preserve
> compatibility and simplicity compared to the rewrite tax and inherent
> message-passing serialization overhead and restrictions.
OK.
> It's not at all clear to me we should jump on message-passing and
> throw JS object sharing cross-thread, given the trade-offs.
That's fair. Perhaps it's worth examining the exact tradeoffs?
>> How does that play with your suggestions of source-compat for
>> nsIThread-using addons?
>
> Nick Nguyen may have data on how many addons at a.m.o have binary
> components, but they are few and far between. My concern with Category
> 2 was about, as noted above, "[p]ure-JS XPConnect-based cross-thread
> JS ..." in apps as well as addons.
This has nothing to do with binary components so far. Binary components
aren't passing JS runnables to nsIThread, by and large, I bet. ;)
I guess it wasn't clear to me whether your wrapper proposal would be
source-compatible with existing nsIThread users (in that the nsIThread
guts or XPConnect or some other such centralized platform piece would
handle creating wrappers).
>> I'm not sure how that case will help the situation where an addon wants
>> to run some code on the non-main thread. It has to create the Function
>> to run on the main thread (that's where it's already running). Then
>> what happens?
>
> The nsIRunnable-implementing JS object would be wrapped automatically,
> for the wrapper proposal to maintain nsIThread-related source
> compatibility. This would have to happen in xpcom/threads code, using
> new JS API.
Aha, ok.
>> What proxies/wrappers will this
>> setup create, and how will it fulfill the goal of running stuff on a
>> background thread without interfering with the main thread's execution
>> in any way?
>
> Consider what happens today: we have pervasive ownercx-testing/
> js_LockObj/js_LockScope/js_{Get,Set}SlotThreadsafe costs to ensure
> thread safety in the JS engine for all native objects.
Yep.
> We want these costs moved down into the wrapper JSObjectOps
> implementation, leaving native objects truly lock-free and single-
> threaded/thread-unsafe.
OK, so the wrapper will only handle the locking (on all threads, not
just the worker thread). It won't do things like actually run things on
the main thread. That wasn't clear.
So will the things the runnable closes over become wrapped at use time,
then (whenever the runnable actually touches them)?
-Boris
Brendan Eich
> On 3/3/10 2:29 AM, Brendan Eich wrote:
>
> > Using it wrong is one thing -- people use Windows APIs and (from
> > drivers or modules) even kernel internals wrong and if their code
> > survives the process and becomes popular, it may even need to be
> > supported, or at least not summarily broken at a certain release date.
>
> OK... but see below.
I'm still not sure we C++ hackers get this -- I could be wrong, too,
but I just heard (from Jorge Villalobos via Nick Nguyen) that there
are hundreds of addons that contain binary components. Different topic
(related if these use nsIThread and mess with ST XPCOM objects) but
that's a lot. Then there are the XUL apps, and the XUL dark matter.
I think we have a successful platform, which means one with bugs to
fix. My point remains that we should not summarily break and say
"port" -- especially if what to port to is brand new or even semi-
vapor-state.
That judgment, which I think is simple prudence, combined with need to
land, bake, and nightly-ship if not beta-release the new JS thread/GC
code, says to me we have to keep things "working".
> > Yeah, but I don't think you can pull it off -- not as described. You
> > shouldn't want to try, anyway, since the downside risk is larger than
> > the risks people take today using XPConnect cross-thread.
>
> The risk people take now is that it's easy to produce
> crashes/hangs/leaks without the extension author realizing it and
> without the user realizing that the extension is causing these problems.
Yes, I see this. It's hard to quantify, but it wouldn't trade off on
the same yardstick against the downside risk I'm citing, anyway.
> So for _us_ the downside risk of the current extension threading model
> is huge, as far as I can see. That risk being random
> crashes/hangs/leaks the user will blame on us.
Developers leaving because we break them hard with a big or unknown
porting tax are the threat I'm concerned about. We don't get them
back. Since addons are "long tail" they may go to Chrome/chromium and
not even lose users -- they may even pull users. If this turns into a
trend and lead users go, it adds more grist to the market-share-
decline mill.
Net Apps market share numbers have issues, we're doing fine, etc. --
I'm not trying to digress on this or invite debate -- we really do not
know how to judge risks here, or even put them in comparable cost
metrics if we could judge probabilities. But we have bugs to fix and
better-APIs to develop and evangelize, no matter what. In the mean
time, to avoid stalling better JS threads and GC I think we need to
keep more compatibility than you seem to.
> > Yes, this needs to be fixed, with better APIs brought up before old
> > ones go away
>
> Well, sure.
Really? If you believe that then JS thread-local GC heaps are going to
be waiting a while on the better APIs to be designed, developed,
stabilized, documented and evangelized into use such that we can break
crufty old cross-thread XPCOM scripting.
I don't want to wait for thread-local GC heaps, proptrees, etc. Lack
of them is a competitive issue now, again on a different cost metric
than crashes due to MT addons, or developer alienation due to API
breaks. But I think we can get thread-local GC heaps, etc. without
breaking, and that is why I'm here.
Like Captain Kirk, I don't believe in the no-win scenario. But maybe
Kirk would just blow up the old APIs and leave it to Scotty to make
new ones in 59 seconds... ;-)
> >> 1) Create working message passing API.
> >> 2) Make nsIThread noscript.
> >> 3) Make whatever changes couldn't handle scriptable nsIThread.
>
> >> if we decide to get rid of scriptable nsIThread.
>
> > Who does 3, when in relation to the release date that includes 2?
>
> Did you mean 2 and 1 respectively?
No, 3 and 2. Because 3 has to be done before 2 in my view, and both
before we can get on with shipping (even in beta) local JS GC heaps
etc.
Let's stipulate 1. I don't really think it's hard, but it is not a
panacea.
> 3 and 2 could happen in the same release. You could make the case that
> there should be a release that contains 1 but hasn't had 2 happen yet to
> allow migration, I guess.
You guess? I've been too subtle, it seems!
But even if in the same release, the JS local heap change can't land
before 3 is far enough along.
> > It's not at all clear to me we should jump on message-passing and
> > throw JS object sharing cross-thread, given the trade-offs.
>
> That's fair. Perhaps it's worth examining the exact tradeoffs?
Maybe, but tradeoffs vary and addon devs have mixed strength. The best
way I know to deal with such an environment (like changing JS on the
web) is to put in new carrots to draw the horses away from the toxic
old vegetables. No sticks, those are counterproductive in competitive
markets, even with carrots, unless you have market power of the quasi-
monopoly kind (MSFT, AAPL).
> >> How does that play with your suggestions of source-compat for
> >> nsIThread-using addons?
>
> > Nick Nguyen may have data on how many addons at a.m.o have binary
> > components, but they are few and far between. My concern with Category
> > 2 was about, as noted above, "[p]ure-JS XPConnect-based cross-thread
> > JS ..." in apps as well as addons.
>
> This has nothing to do with binary components so far. Binary components
> aren't passing JS runnables to nsIThread, by and large, I bet. ;)
I know; I said so too. I thought you were asking about addons with
binary code that uses nsIThread and touches the DOM, Windows, etc. --
such addons exist.
> I guess it wasn't clear to me whether your wrapper proposal would be
> source-compatible with existing nsIThread users (in that the nsIThread
> guts or XPConnect or some other such centralized platform piece would
> handle creating wrappers).
That's the idea -- JS source compatibility.
The JS API would change, as I noted last time.
> OK, so the wrapper will only handle the locking (on all threads, not
> just the worker thread). It won't do things like actually run things on
> the main thread. That wasn't clear.
Sorry, trying to clarify. We have xpcom/proxy already, but that's not
this new idea.
> So will the things the runnable closes over become wrapped at use time,
> then (whenever the runnable actually touches them)?
Depends on whether we give up the request model. If we do, that would
be too late. If we keep the request model (shorter path, always good
even if only as an intermediate step), then we could lazily
wrap/"become".
/be
johnjbarton
> On Mar 3, 2:50 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> > > It's not at all clear to me we should jump on message-passing and
> > > throw JS object sharing cross-thread, given the trade-offs.
>
> > That's fair. Perhaps it's worth examining the exact tradeoffs?
>
> Maybe, but tradeoffs vary and addon devs have mixed strength. The best
And the meaning of "message passing" varies. We can end up with big
objects and simple messages or we can end up with objects the size of
functions and reinvent RPC.
The overall goal discussed here is to create some large chunks with
single-thread logic, obviously the right direction. (I think multi-
threading and JS should never meet) But what is missing for me is
discussion of what the chunks are in a browser. It seems that at least
some of discussions ( not this one) around consider fine-grained
interactions between processes and this worries me, even or especially
if it is done under the covers.
Historically addon devs have had great success with chunky message-
passing solutions and terrible failures with multi-threading. That is
true for all developers: the failures of multi-threading systems
typically come early and manifest strongly. Object sharing and
message passing both succeed when the object model is clear and
chunky; both fail when the model is muddy and the particles small.
But the failure mode of message-passing systems comes late, long after
the demos are done, the production code is written, and we finally see
all the messages.
jjb
Boris Zbarsky
> I'm still not sure we C++ hackers get this -- I could be wrong, too,
> but I just heard (from Jorge Villalobos via Nick Nguyen) that there
> are hundreds of addons that contain binary components.
Out of how many total add-ons?
> I think we have a successful platform, which means one with bugs to
> fix. My point remains that we should not summarily break and say
> "port" -- especially if what to port to is brand new or even semi-
> vapor-state.
I agree with the "especially" but not with the part before that,
depending on circumstances.
> That judgment, which I think is simple prudence, combined with need to
> land, bake, and nightly-ship if not beta-release the new JS thread/GC
> code, says to me we have to keep things "working".
So the key here is that you see the new JS thread/GC code landing in a
timeframe which would not allow creation of a new threading API for
extensions? Do we have time estimates here? How much (if at all) could
the new thread/GC code development be sped up if it didn't have to cater
to the extensions case?
>> The risk people take now is that it's easy to produce
>> crashes/hangs/leaks without the extension author realizing it and
>> without the user realizing that the extension is causing these problems.
>
> Yes, I see this. It's hard to quantify, but it wouldn't trade off on
> the same yardstick against the downside risk I'm citing, anyway.
Presumably because you're talking about risk for us, not our users or
extension authors?
> Developers leaving because we break them hard with a big or unknown
> porting tax are the threat I'm concerned about.
I understand this. What fraction of our extension developers (and maybe
separately of popular extension developers):
1) Use nsIThread
and
2) Are likely to leave if asked to port to an existing and working new
threading API?
> Since addons are "long tail" they may go to Chrome/chromium
Assuming what they're trying to do can be done there....
> and not even lose users -- they may even pull users. If this turns into a
> trend and lead users go
I think we have a bigger chance of lead users going due to perceived
speed/bloat/crash stuff than due to long-tail extensions moving to
Chrome. Imho, totally gut-feeling based on what I've been seeing around
the 'net, take with salt-mines.
> we really do not know how to judge risks here,
Agreed.
> In the mean
> time, to avoid stalling better JS threads and GC I think we need to
> keep more compatibility than you seem to.
Right, back to scheduling. I defer to you on that one; I have no idea
what your planned schedules look like.
> Really? If you believe that then JS thread-local GC heaps are going to
> be waiting a while on the better APIs to be designed, developed,
> stabilized, documented and evangelized into use such that we can break
> crufty old cross-thread XPCOM scripting.
I believe that we could break it once it's designed, developed.
Stabilization and the rest can happen in parallel as people update
extensions. But again, depends on timing. And I realize that you don't
agree with this belief.
>>>> 1) Create working message passing API.
>>>> 2) Make nsIThread noscript.
>>>> 3) Make whatever changes couldn't handle scriptable nsIThread.
>>
>>>> if we decide to get rid of scriptable nsIThread.
>>
>>> Who does 3, when in relation to the release date that includes 2?
>>
>> Did you mean 2 and 1 respectively?
>
> No, 3 and 2. Because 3 has to be done before 2 in my view
Right; I got that. ;)
Here's the real question. Do we think we could design a
message-passing-like API for extensions in about a week or two at most?
If not, you're probably right that we shouldn't wait on it...
> Let's stipulate 1. I don't really think it's hard, but it is not a
> panacea.
It doesn't have to be a panacea; just better than current nsIThread.
>> 3 and 2 could happen in the same release. You could make the case that
>> there should be a release that contains 1 but hasn't had 2 happen yet to
>> allow migration, I guess.
>
> You guess? I've been too subtle, it seems!
>
> But even if in the same release, the JS local heap change can't land
> before 3 is far enough along.
Agreed.
> Maybe, but tradeoffs vary and addon devs have mixed strength. The best
> way I know to deal with such an environment (like changing JS on the
> web) is to put in new carrots to draw the horses away from the toxic
> old vegetables. No sticks, those are counterproductive in competitive
> markets, even with carrots, unless you have market power of the quasi-
> monopoly kind (MSFT, AAPL).
We have that to some extent in our extension ecosystem. For example, if
we made passing an object that entrains a Window to an nsIThread as a
runnable throw, and made the exception explain why, I bet people would
fix it pronto.
>> So will the things the runnable closes over become wrapped at use time,
>> then (whenever the runnable actually touches them)?
>
> Depends on whether we give up the request model. If we do, that would
> be too late. If we keep the request model (shorter path, always good
> even if only as an intermediate step), then we could lazily
> wrap/"become".
Sounds like we need to keep the request model, then. Otherwise you have
to wrap the entire reachable graph, including through native getters, no?
-Boris
Wes Garland
> So the key here is that you see the new JS thread/GC code landing in a
> timeframe which would not allow creation of a new threading API for
> extensions?
Will web-worker threads work from extensions? I understand this. What
fraction of our extension developers (and maybe separately of popular
extension developers):
>
> 1) Use nsIThread
>
> and
>
> 2) Are likely to leave if asked to port to an existing and working new
> threading API?
>
I should point out, it's possible that a given program which relies on the
current threading model may be difficult or impossible to port to a
shared-nothing/message-passing system. Although, I suppose, adding cheap
catchall getter/setter on Object.prototype which emulates promiscuous object
sharing might be a solution for those folks (which they could implement
themselves).
> I think we have a bigger chance of lead users going due to perceived
> speed/bloat/crash stuff than due to long-tail extensions moving to Chrome.
> Imho, totally gut-feeling based on what I've been seeing around the 'net,
> take with salt-mines.
>
>
I read the 'net slightly differently. People tend to switch from IE to
Firefox and then maybe to something-else. Firefox's competitive advantages
over other-non-MS browsers are name recognition and extensions, however
Firefox sheds users due to rendering speed (somewhat) and memory leaks (a
lot). In fact, I've, ah, been loading GMail in IE8 this week, I think 3.5.7
is leaking on me (sorry, haven't had time to collect metrics).
>
> Here's the real question. Do we think we could design a
> message-passing-like API for extensions in about a week or two at most? If
> not, you're probably right that we shouldn't wait on it...
>
>
Web workers' message passing API? (I haven't read it, but it makes sense
to me to reuse it if it's good enough)
> Sounds like we need to keep the request model, then. Otherwise you have to
> wrap the entire reachable graph, including through native getters, no?
>
>
Without the request model, will it be possible for embedders to take
advantage of opportunistic other-thread GC while the main JS thread is
blocked on I/O? I do this now, two contexts in the same rt, and a thread
that JS_MaybeGC()'s regularly. When memory pressure grows, the GC thread
waits for the other thread to suspend its request and then it collects.
This is a great for the type of work I do (often heavily I/O bound) because
I effectively pay nothing for GC on multicore systems.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Boris Zbarsky
> Will web-worker threads work from extensions? I understand this. What
> current threading model may be difficult or impossible to port to a
> shared-nothing/message-passing system.
That's true; that didn't seem to be the case for the extensions I looked at.
>> I think we have a bigger chance of lead users going due to perceived
>> speed/bloat/crash stuff than due to long-tail extensions moving to Chrome.
>> Imho, totally gut-feeling based on what I've been seeing around the 'net,
>> take with salt-mines.
>>
>>
> I read the 'net slightly differently. People tend to switch from IE to
> Firefox and then maybe to something-else. Firefox's competitive advantages
> over other-non-MS browsers are name recognition and extensions, however
> Firefox sheds users due to rendering speed (somewhat) and memory leaks (a
> lot).
Your last clause there is exactly what I was saying. Are we in violent
agreement, or am I missing something?
>> Here's the real question. Do we think we could design a
>> message-passing-like API for extensions in about a week or two at most? If
>> not, you're probably right that we shouldn't wait on it...
>>
> Web workers' message passing API? (I haven't read it, but it makes sense
> to me to reuse it if it's good enough)
Right, that was the thinking.
-Boris
Brendan Eich
> On 3/3/10 8:05 PM, Brendan Eich wrote:
>
> > I'm still not sure we C++ hackers get this -- I could be wrong, too,
> > but I just heard (from Jorge Villalobos via Nick Nguyen) that there
> > are hundreds of addons that contain binary components.
>
> Out of how many total add-ons?
This was about AMO, so hundreds out of ~12,000.
> I believe that we could break it once it's designed, developed.
> Stabilization and the rest can happen in parallel as people update
> extensions. But again, depends on timing. And I realize that you don't
> agree with this belief.
From what I can see there's almost no evidence for your belief. We
have JEPs based on first principles and ideas or demos, but not a hard
survey of what ~12k addons actually do, how they currently do it
(weighted however you like based on addon popularity or long tail
integration).
> > Let's stipulate 1. I don't really think it's hard, but it is not a
> > panacea.
>
> It doesn't have to be a panacea; just better than current nsIThread.
Sorry, no. Message passing does not exist on the same axis as
nsIThread. It's not "better" in some complete or consistent sense,
unless you have a priori commitments to it, and therefore no need to
share object references that might allow mutation, or else your addon
can tolerate the serialization/deserialization overhead.
My point is not only that message passing is not a panacea --
certainly neither is nsIThread! yet it's the devil we ship -- rather,
my point is that the two are not even commensurate. You can't just say
"message passing replaces nsIThread, start porting."
We talked this week to Leo Meyerovich at Berkeley about the general
problem of JS security in mixed-trust mashups, and Leo made the point
I'm making spontaneously: the shared-nothing model is not being taken
up by web devs. It is a costly model shift from the current mutable
big graph model, especially across the broad bell curve of hackers.
(We agreed that VM-level default-deny policy that monitors origin
crossings is better, and then we productively debated AOP vs. proxies/
wrappers for mechanism underlying that policy.)
I suspect Leo's right. Collin Jackson urged people to use iframe
sandboxes and postMessage to build secure mashups at W2SP 2009. Alas,
doing so is neither particularly easy nor compelling. If mashups or
our Firefox addons were easy to isolate into modules that communicate
infrequently through string-equivalent messages, we would know, we'd
see more such a-priori mashups, and we'd have less of a debate here.
Again, I'm not sure where the truth lies. It could be that most addons
could be ported to such a model, but we'd have to try at scale, in
order to find out. And if we pull nsIThread prematurely and it turns
out we're wrong (enough -- long tail wrong), devs will be stuck with
no solution. Then we'd be facing another "restore LiveConnect" moment.
> > Maybe, but tradeoffs vary and addon devs have mixed strength. The best
> > way I know to deal with such an environment (like changing JS on the
> > web) is to put in new carrots to draw the horses away from the toxic
> > old vegetables. No sticks, those are counterproductive in competitive
> > markets, even with carrots, unless you have market power of the quasi-
> > monopoly kind (MSFT, AAPL).
>
> We have that to some extent in our extension ecosystem. For example, if
> we made passing an object that entrains a Window to an nsIThread as a
> runnable throw, and made the exception explain why, I bet people would
> fix it pronto.
If they fixed it by not doing that, sure. What if the fix is not so
easy?
> >> So will the things the runnable closes over become wrapped at use time,
> >> then (whenever the runnable actually touches them)?
>
> > Depends on whether we give up the request model. If we do, that would
> > be too late. If we keep the request model (shorter path, always good
> > even if only as an intermediate step), then we could lazily
> > wrap/"become".
>
> Sounds like we need to keep the request model, then. Otherwise you have
> to wrap the entire reachable graph, including through native getters, no?
Yes, the Ice-9 disaster problem looms if we don't keep requests. It
could be limited by new policy, but we won't get there (and bring any
addon devs with us) without going through the shorter path: lazy wrap/
becomes.
/be