Re: Threading and runtime / context sharing

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

_______________________________________________
dev-tech-js-engine mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine