Right now we have pretty good assurances of thread safety when accessing the runtime from a context, due to the constraints on when this method is available and associated assertions. The runtime can also be accessed from individual cells, from compartments and from zones, and there are no thread safety assertions here. The attached patch adds assertions, changing runtime() methods on these constructs into runtimeFromMainThread() accessors which check thread safety. There is also a runtimeFromAnyThread() in a couple places, which is used by GC methods that are protected by the runtime's GC lock, and by post barriers, which are not threadsafe (will fix this in a future patch).

On first glance, this looks fine. I'm worried about removing the runtime->needsBarrier() checks though. Are you sure that's okay? The details are in bug 852802.

Update with runtime->needsBarrier() checks restored. Per IRC discussion right now these will race in GGC builds though it should be harmless (zone->needsBarrier() will never be true) and this should get fixed down the line by bug 887030.

Comment on attachment 784586 [details] [diff] [review] patch (f0ce0463bd65) Review of attachment 784586 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/ion/shared/CodeGenerator-shared.cpp @@ +45,5 @@ > #ifdef DEBUG > pushedArgs_(0), > #endif > lastOsiPointOffset_(0), > + sps_(&GetIonContext()->runtime->spsProfiler, &lastPC_), This sorta suggests that PJS code probably doesn't interact well with the profiler. Oh well I guess.