Subj : Re: Can I have more than one runtime to facilitate multiple threads? To : Chris Davis From : Brendan Eich Date : Mon Jun 30 2003 03:01 pm Chris Davis wrote: > Can I achieve "thread safety" by having each thread create its > own runtime, & only ever have a particular thread reference its > runtime and contexts that only it created? Not without still defining JS_THREADSAFE and linking with NSPR. See many postings in this group, e.g. . > Some background...under Linux, I had well over 200 threads using an > extensive > amount of javascript using the threadsafe version of Spidermonkey, > nspr, etc. > It worked, but I located a performance bottleneck in JScalls' use of a > single > runtime across threads. By "bottleneck" I mean it appears all these > threads were continually waiting on locks inside JS and didn't get > enough processor time. What locks? What stacks? What version of SpiderMonkey were you using? > When I split the application out into 200 single threaded processes, a > huge > performance boost (CPU idle time went way up from zero) was achieved, > but now of course it uses a lot more memory. How do you know where the CPU was in the single-process case? > As I browse the JS library code, it appears all(?) variables and such > are stuffed into the runtime and contexts, which makes it appear this > concept would work, even if not using the threadsafe JS #defines and > npsr. You're overlooking jsarena.c, jsdtoa.c, and jsstr.c global variables and locks, at the least. However, you might try using more runtimes, as apparently you have no need to share access to objects among threads (or processes, which share no memory implicitly). But if using more than one runtime shows a big speedup, you must not be using a recent version of the engine. Since the fix for bug 54743 went in at the end of 2000, JS has avoided object lock overhead for all objects used by only one thread. If you are using a version of the engine with that lock-free optimization, then we need to see exactly where the CPU is in the single process case. Maybe you're using one thread to create all other threads' objects, which could defeat the optimization (just a thought). More data, particularly from a hierarchical profiler, or just poor man's profiling with a debuggger (interrupt the process often and see where the stacks tend to fall), is needed. /be /be .