Re: Threading and runtime / context sharing

On Monday, 13 November 2017 17:08:35 UTC+11, Dmitri  wrote:
> Hi, 
> 
> I am trying to understand if it is possible to share compiled scripts between threads. 
> 
> In SM 1.7 we had a single cache of compiled scripts used directly by X number of threads. That worked very well and significantly improved the performance of our application. 
> 
> SM 24 doesn't allow mixing compilation and execution threads anymore. 
> A simple solution would be to have a copy of the cache per each X thread. However, that consumes lots of memory and doesn't scale. 
> 
> Is it possible to have a pool of Y threads to serve "JS requests" from X threads? 
> 
> Let's for example, Y = 1, X = 2. Y thread would create a triplet of JSRuntime, JSContext, and Global object. Then it would create X1 and X2 objects and would associate compartments with X1, X2. 
> X1 and X2 would be children of the global object. 
> 
> To compile a script: 
> JS::Compile(cx, options, srcBuf, script);  - SM 45 or 
> JS::Compile(cx, global_obj, options, srcBuf, script); - SM before 39 
> 
> Does it matter what compartment is used for compilation? 
> 
> To execute a script for thread_Xi: 
> JS_EnterCompartment(cx, Xi); 
> JS_ExecuteScript(cx, scopeChain, script); //scopeChain starts with has Xi 
> JS_LeaveCompartment(cx, oldCompartment); 
> 
> Will that work? If so will that protect X1 data from X2 code? Or X2 code will be able to walk up the scope chain, access global_obj and then access Xi scope chain? 
> 
> thanks, 
> -Dmitri 
> 
> On Saturday, 29 July 2017 04:52:24 UTC+10, Bill McCloskey  wrote:
> > Brian Hackett is the expert since he wrote all the recent threading code. I
> > think it would help to ask a more concrete question, though.
> > 
> > -Bill
> > 
> > On Fri, Jul 28, 2017 at 11:12 AM, Bobby Holley
> > wrote:
> > 
> > > The landscape of this code has changed significantly since the above posts
> > > on this thread. Bill (CCed) is the right person to ask about it now.
> > >
> > > On Fri, Jul 28, 2017 at 8:38 AM,  wrote:
> > >
> > >> Hi Bobby, I came to this thread because I'm having the same issue like
> > >> Robin. I have been working with spidermokey as a embeddable engine since
> > >> versión 1.5 (currently porting some develop from 1.8.5 to 24).  For years I
> > >> avoided to use v8 as an alternative engine because the limitation in
> > >> multithreading environment and I will be glad to work in this issue to keep
> > >> me, and all others developers, away from other engines.
> > >> So, some mentoring will be welcome.
> > >>
> > >> On Tuesday, July 28, 2015 at 4:11:12 PM UTC-3, Bobby Holley wrote:
> > >> > On Mon, Jul 27, 2015 at 10:48 PM, Terrence Cole 
> > >> wrote:
> > >> >
> > >> > > I think it is still presumed to be slow, so is rarely used; at least
> > >> this
> > >> > > is the case in the GC. The GC's main use at the moment is for making
> > >> > > assertions about global state in deep call stacks where it's
> > >> cumbersome to
> > >> > > thread a context, particularly if it has to be debug-only.
> > >> > >
> > >> >
> > >> > Great.
> > >> >
> > >> >
> > >> > >
> > >> > >
> > >> > >> If so, I think we should do that (to avoid more dependencies), which
> > >> has
> > >> > >> the added benefit of solving Robin's problem.
> > >> > >>
> > >> > >
> > >> > > I think this is a reasonable plan, although, as with anything
> > >> threading
> > >> > > related, caution is warranted lest we end up back in the dire
> > >> straights
> > >> > > that caused us to go strictly single-threaded in the first place.
> > >> > >
> > >> >
> > >> > I'm not suggesting a change to the threading model. I'm just suggesting
> > >> > that we do all of our threading operations (TLS lookups, "are we on this
> > >> > thread", etc) indirectly via a virtual methods on an interface that the
> > >> > embedder implements.
> > >> >
> > >> > Doing this sooner rather than later will probably make our lives easier
> > >> in
> > >> > the long run. Robin, would you be willing to do this if someone mentors
> > >> you?
> > >>
> > >> _______________________________________________
> > >> dev-tech-js-engine mailing list
> > >> [email protected]
> > >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
> > >>
> > >
> > >

I run few tests with SM 45. Yes, it is possible to have a JS thread that serves JS execution requests from few other threads. To separate data I created few global objects and run client requests in separate compartments.
_______________________________________________
dev-tech-js-engine mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine