access JSContext via fast TLS (stop passing by value)

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
7 years ago
5 years ago

People

(Reporter: luke, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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

7 years ago
Depends on: 650361
(Reporter)

Updated

7 years ago
Blocks: 650361
No longer depends on: 650361
(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.
(Reporter)

Comment 3

6 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

5 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
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
> 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.
You need to log in before you can comment on or make changes to this bug.