Closed
Bug 650357
Opened 14 years ago
Closed 11 years ago
access JSContext via fast TLS (stop passing by value)
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: luke, Unassigned)
References
Details
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.
Reporter | ||
Updated•14 years ago
|
Comment 1•12 years ago
|
||
(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.
Comment 2•12 years ago
|
||
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.
Reporter | ||
Comment 3•12 years ago
|
||
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.
Reporter | ||
Comment 4•11 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Comment 5•11 years ago
|
||
> We already have the JSRuntime in TLS
Is there API for getting it? Or should I file a separate bug on this?
Comment 6•11 years ago
|
||
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.
Comment 7•11 years ago
|
||
Excuse me, just Niko: Shu declaims all knowledge of this change.
You need to log in
before you can comment on or make changes to this bug.
Description
•