It appears that TLS is fast (3-4 inline ops) on all platforms - Windows and linux have __thread / __declspec(thread) - Mac OS X has _pthread_getspecific_direct (http://www.opensource.apple.com/source/Libc/Libc-594.1.4/pthreads/pthread_machdep.h) Although the ops are dependent loads, this should be fast enough to replace explicit cx parameterization with TLS. Of the hot uses of cx, we should be able to do smart things like baking in pointers to jit code or caching in local vars.
(In reply to Luke Wagner [:luke] from comment #0) > It appears that TLS is fast (3-4 inline ops) on all platforms > - Windows and linux have __thread / __declspec(thread) > - Mac OS X has _pthread_getspecific_direct > (http://www.opensource.apple.com/source/Libc/Libc-594.1.4/pthreads/ > pthread_machdep.h) > > Although the ops are dependent loads, this should be fast enough to replace > explicit cx parameterization with TLS. Of the hot uses of cx, we should be > able to do smart things like baking in pointers to jit code or caching in > local vars. Is this bug still relevant? To my knowledge, SpiderMonkey officially doesn't support multithreading anymore.
It's still relevant. Right now code has to create JSContexts then use them sanely. And you can use more than one context on a thread. And contexts contain various bits of stateful information that mean that, right now, you can't just have them start using a single context per thread. All that needs to be fixed before this bug can progress. But it'll definitely progress.
Agreed. Also, single-threaded or not, it is useful not to have to manually pass around 'cx'. I think TLS has enough overhead that the hottest uses would hurt our perf. However, in such cases we can just pass/hold 'cx' explicitly. I suspect just having JSNative and jit stubs continue to take a 'cx' parameter would cover maybe 90% of the hot cases. It is easy enough to measure by artificially making TLS access 100x slower by, say, cos() a bunch, and then seeing where cos() shows up in the profiler.
We already have the JSRuntime in TLS and the goal is to rm JSContext altogether (bug 650361, but entirely gated on bholley's heroic xpconnect/DOM work), so nothing to do here.
> We already have the JSRuntime in TLS Is there API for getting it? Or should I file a separate bug on this?
Well, the JSRuntime /was/ in TLS. Shu and Niko thought this might be dangerous to expose to parallel arrays so they replaced it with a new PerThreadData struct that has nothing in it.
Excuse me, just Niko: Shu declaims all knowledge of this change.