On Tue, Oct 30, 2012 at 3:11 AM, Terrence Cole <tc...@mozilla.com> wrote: > On 10/29/2012 05:32 PM, Dave Mandelin wrote: >> I was reviewing one of the River Trail patches today and I noticed that it >> had to add JS_THREADSAFE everywhere. This seems wrong to me. IIRC, >> JS_THREADSAFE originally was a build configuration parameter used to decide >> between: >> >> - I want a multithreaded engine, at the cost of some locking >> overhead for certain common operations, and >> - I want a single-threaded only engine >> >> AFAIK, that distinction is just about gone, so JS_THREADSAFE is now mostly >> legacy cruft (the name certainly is), but has been pressed into service to >> decide between: >> >> - I want an engine that uses threads to make stuff faster, like >> GC, compilation, and source compression, and >> - I want an engine that doesn't use extra threads for that >> >> Is this still a choice worth making? Most of our users have 2+ cores now, >> the future is believed to be even more parallel, and everyone wants >> performance and responsiveness. >> >> How about we just say it's a library that uses threads, and give (preferably >> runtime) options to control that usage in ways that people need? I think >> requiring NSPR to build on Windows is the initial primary pain point. What's >> the easiest way to hack the build system around this? NSPR is in a full >> checkout, so it doesn't seem crazy to build NSPR and then SpiderMonkey. > > I think we want this gone. There are some bugs for this already: > 720018, 763800, 772722, and 773491.
Even if we keep it in the short to medium term (and , we should at least try to contain the use of JS_THREADSAFE as much as possible. In bug 763800, we removed a lot of gc-related uses from various files by making GCHelperThread's interface the same for non- and threadsafe builds. I haven't looked at the River Trail patch enough to know for sure, but given that parallel arrays should work the same if they can only run sequentially, I hope that implementing something similar for them isn't too hard. But then again, maybe finishing the work on 773491 and 720018 after it is the better way forward even in the short term. _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
