The web worker script can be suspended and run again on another native thread depending on the worker scheduling. This means that all the caches and the jited code that the script has created will have to be regenerated again. To offset that we should support transferring JSThread to another native thread.

I think we just want to stop sharing runtimes across threads instead.

(In reply to comment #1) > I think we just want to stop sharing runtimes across threads instead. This is wasteful or prohibitively expensive in embeddings that do share frozen objects among threads, including Firefox with workers and "structured cloning" of messages. See bug 550275. /be

Is there proof for this? I am not opposed to sharing address space. I would even be ok with sharing ->dslots. JSObjects I would prefer to have unshared, in each heap. Nobody uses workers, and even if they do, there aren't that many at any given time. The heap is at most 32MB and being single threaded and going fast (and low complexity) seams like quite a noble goal here.

(In reply to comment #3) > Is there proof for this? fwiw, I don't see how comment 1 should be dismissed out of hand. Comment 0 seems like it might bring quite a lot of complexity, which is also wasteful, just in a different way.

Yeah, the runtime switch is definitely much more complex to implement. If Igor can fix #0 it would no longer affect benchmark scores. The "is there proof for this" comment was aiming at #2. I am not convinced that data sharing between workers justifies the overhead of a shared runtime.

We want single-threaded heaps but that does not imply runtime per thread. We have a ton of code shipping now using XPConnect for workers as well as main thread JS. It all uses one runtime. The dependencies are deep. The sharing benefits are not to be dismissed out of hand either. At this point you have to put up a lot of code to prove runtime per thread should be the one and only way. Are you going to write that code? The single-threaded heap idea requires new code too, but it does not break all the existing code using one runtime among many threads. /be

In short, talk is cheap. Either we break existing code and rewrite a lot; or we keep existing code and solve the MT heap problem we need to solve with new code. I know which one gets into nightlies, gets tested, and gets shipped sooner. It also has sharing benefits that, again, are not to be dismissed. Argumentum ad ignorantiam still cuts both ways. We can't prove that copying vs. sharing is either bad or tolerable (it's not good per se, only good if it leaves us with simpler code, all else equal). /be

Ben wrote the code (bug 649537) \o/