At the moment, the method JIT associates its compiled data with a JSScript by having a JSScript point to its compiled code. Since JSScripts may be shared between threads and the compiled code is mutable (PICs, lazy compilation, etc), we need the compiled code to also be associated with the thread. An initial and efficient approach would be to add a word to JSScript that starts at zero and gets set with a CAS to the thread id of the compiled code. Any thread which sees this field already set would have to do something else. We might be tempted to say "well, this is rare/bad, we shouldn't worry and just fall back to the interpreter", however this can happen with plain web workers (start executing on one thread, suspend, activate on another thread). Thus, we need a more general mapping, e.g. a hash table in JSThreadData from JSScript* to code, as a fallback if the JSScript-threadid initial check fails. Since this logic needs to happen on every inline method call (a hot path) this could (transient) be a slowdown. We can avoid this performance ding (in fact, go even faster than what we have now) with bug 551339.

(In reply to comment #0) > however this can happen with plain web workers > (start executing on one thread, suspend, activate on another thread). This can be addressed if would allow to transfer JSThread from one native thread to another. Then a suspended web worker can just JSThread with it to a new thread eliminating this problem.

(In reply to comment #1) That sounds delightful. Ben, do you see any difficulties with that?

From what I remember this seems fine.

There may be some positive interaction between this bug and the compartmentalization underway as described in https://wiki.mozilla.org/JavaScript:SpiderMonkey:GC_Futures. Viz., the changes to web workers made for them to play well in a compartmentalized world might simplify what we are trying to achieve here.

I just talked about this with jorendorff and MikeM on IRC, and it looks like jorendorff's GC compartments work [1] is going to solve the problem for us. Summary of that discussion: - The API will allow only one thread to run in a given script at a time. This fits in well with the basic idea of single-threaded compartments, and shouldn't cause any major problems for Gecko. Minor problems will get worked out by changing Gecko to use the new API correctly. - Users that want to run a given script in multiple threads in parallel in JM will clone the scripts.

Compartments delivered.