Threading and runtime / context sharing

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Threading and runtime / context sharing

Robin Ehrlich
We are in the process of upgrading to v31 from v17 and it is turning out to
be a major development effort.

We are confused by how runtimes and contexts can be switched from one thread
to another. In v17 the API calls JS_SetRuntimeThread() and
JS_ClearRuntimeThread supported this operation. These API calls are no
longer available.

In our application we use multiple runtimes each with one context to
guarantee that data is not shared between users.

v31 suggests using only one runtime. Is it shared across all threads? Is a
context assigned to a thread or can it be used by any thread? Can we be
certain that data is never shared between contexts?

Thanks for any advice,
Robin Ehrlich

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Boris Zbarsky
On 7/16/15 9:58 AM, Robin Ehrlich wrote:
> We are confused by how runtimes and contexts can be switched from one
> thread to another.

They can't be.  SpiderMonkey uses thread-local storage at this point, so
a runtime is tied to a particular thread.

> In v17 the API calls JS_SetRuntimeThread() and
> JS_ClearRuntimeThread supported this operation.

Well, sort of.  More precisely, in v17 those calls told the runtime
which thread you planned to use it on, which mostly affected asserts as
far as I can tell...

> v31 suggests using only one runtime. Is it shared across all threads?

A runtime in current spidermonkey is tied to a particular thread.

> Is a context assigned to a thread or can it be used by any thread?

The former.  A context is tied to a particular runtime.  And ideally
you'd just use a single context per runtime, in preparation for contexts
just going away altogether or becoming an alias for the runtime... see
more below.

> Can we be certain that data is never shared between contexts?

Data is not tied to contexts in any way.  At this point contexts are
more or less vestigial.

Data is tied to particular compartments/globals in the sense that
cross-compartment references require special proxy machinery.  I wonder
whether it's possible to just turn off creation of cross-compartment
wrappers so that you can never get cross-global references, and if so
whether that would address your use case.  It seems like it should be
doable using the same setup that Firefox uses to create its filtering
wrappers for cross-origin objects... but then just throwing on attempts
to create those wrappers.  Or do you need to have multiple global
objects per user?   I guess that should still be possible as long as you
give them different principals and fail cross-origin wrapper creation.

-Boris
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Robin Ehrlich
Thank you for the detailed response. I was afraid that of this response.
That is, runtimes are assigned to a thread and cannot be moved. This is a
major problem for us.

We use JavaScript as our script engine in our HTTP server. We use a
runtime/context to maintain state of a user from one HTTP request to another
(our concept of a session). This works very well for us to maintain random
state information and reuse compiled scripts. Obviously sessions can last a
long time and processing threads will come and go, but we must maintain
state.

From your response it seems that the current version of SpiderMonkey does
not support this architecture. That is a real shame. We have used
SpiderMonkey for many years and we would like to upgrade to a more recent
version.

Do you have any ideas how we can proceed?

Robin


_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
Do we actually use TLS? How does this work with workers, which run on task
queues? In general, I think we need to support running SM on a task queue
(rather than a bonafide OS thread) in order to do worker-y things
efficiently.

On Fri, Jul 24, 2015 at 1:53 PM, Robin Ehrlich <[hidden email]> wrote:

> Thank you for the detailed response. I was afraid that of this response.
> That is, runtimes are assigned to a thread and cannot be moved. This is a
> major problem for us.
>
> We use JavaScript as our script engine in our HTTP server. We use a
> runtime/context to maintain state of a user from one HTTP request to
> another (our concept of a session). This works very well for us to maintain
> random state information and reuse compiled scripts. Obviously sessions can
> last a long time and processing threads will come and go, but we must
> maintain state.
>
> From your response it seems that the current version of SpiderMonkey does
> not support this architecture. That is a real shame. We have used
> SpiderMonkey for many years and we would like to upgrade to a more recent
> version.
>
> Do you have any ideas how we can proceed?
>
> Robin
>
>
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Kyle Huey-2
On Mon, Jul 27, 2015 at 10:49 AM, Bobby Holley <[hidden email]> wrote:
> Do we actually use TLS? How does this work with workers, which run on task
> queues? In general, I think we need to support running SM on a task queue
> (rather than a bonafide OS thread) in order to do worker-y things
> efficiently.

Yes, we do.  See js::TlsPerThreadData.  I'm not sure what workers
you're talking about.  If you're talking about Web Workers, the
JSRuntime for one worker is destroyed before a new one is assigned
that thread, so there's never two JSRuntimes active on a given thread
at any point in time.

- Kyle
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
On Mon, Jul 27, 2015 at 10:54 AM, Kyle Huey <[hidden email]> wrote:

> Yes, we do.  See js::TlsPerThreadData.  I'm not sure what workers
> you're talking about.  If you're talking about Web Workers, the
> JSRuntime for one worker is destroyed before a new one is assigned
> that thread, so there's never two JSRuntimes active on a given thread
> at any point in time.
>

I got the impression from bent last year that we run workers on a task
queue (on top of a threadpool). From the above, I take it this isn't the
case?

If so, does that mean we still limit the number of workers to the number of
OS threads allocated to run them? Is there a reason we haven't switched to
a task queue model, which would decouple the number of worker threads from
the number of OS threads?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Kyle Huey-2
On Mon, Jul 27, 2015 at 10:59 AM, Bobby Holley <[hidden email]> wrote:

> On Mon, Jul 27, 2015 at 10:54 AM, Kyle Huey <[hidden email]> wrote:
>>
>> Yes, we do.  See js::TlsPerThreadData.  I'm not sure what workers
>> you're talking about.  If you're talking about Web Workers, the
>> JSRuntime for one worker is destroyed before a new one is assigned
>> that thread, so there's never two JSRuntimes active on a given thread
>> at any point in time.
>
>
> I got the impression from bent last year that we run workers on a task queue
> (on top of a threadpool). From the above, I take it this isn't the case?

No, we dedicate a thread to a given worker while it is alive.  If it
dies we may reuse that thread if there's another worker waiting to be
scheduled, or we may return it to the operating system if there is
not.

> If so, does that mean we still limit the number of workers to the number of
> OS threads allocated to run them?

Yes.

> Is there a reason we haven't switched to a
> task queue model, which would decouple the number of worker threads from the
> number of OS threads?

Because that's a lot of work, and twenty workers is enough for anyone?

- Kyle
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
On Mon, Jul 27, 2015 at 11:02 AM, Kyle Huey <[hidden email]> wrote:

> No, we dedicate a thread to a given worker while it is alive.  If it
> dies we may reuse that thread if there's another worker waiting to be
> scheduled, or we may return it to the operating system if there is
> not.
>

Ok, thanks for clearing that up.

> Is there a reason we haven't switched to a
>
> task queue model, which would decouple the number of worker threads from
> the
> > number of OS threads?
>
> Because that's a lot of work, and twenty workers is enough for anyone?
>

Sure, but it also means that we have no way to control the total number of
OS threads in the system, which seems like it might be suboptimal as more
and more things start using workers.

Is the "lot of work" mostly confined to dom/workers, or do you know of
other dependencies off the top of your head? Seems like SM TLS would be
one. Are there others?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Kyle Huey-2
On Mon, Jul 27, 2015 at 11:12 AM, Bobby Holley <[hidden email]> wrote:

> On Mon, Jul 27, 2015 at 11:02 AM, Kyle Huey <[hidden email]> wrote:
>>
>> No, we dedicate a thread to a given worker while it is alive.  If it
>> dies we may reuse that thread if there's another worker waiting to be
>> scheduled, or we may return it to the operating system if there is
>> not.
>
>
> Ok, thanks for clearing that up.
>
>> > Is there a reason we haven't switched to a
>>
>> > task queue model, which would decouple the number of worker threads from
>> > the
>> > number of OS threads?
>>
>> Because that's a lot of work, and twenty workers is enough for anyone?
>
>
> Sure, but it also means that we have no way to control the total number of
> OS threads in the system, which seems like it might be suboptimal as more
> and more things start using workers.
>
> Is the "lot of work" mostly confined to dom/workers, or do you know of other
> dependencies off the top of your head? Seems like SM TLS would be one. Are
> there others?

The cycle collector comes to mind.

If we want to do serious architectural work around our threading model
I'd much rather split the main thread into a series of task queues
than muck around with workers.

- Kyle
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
On Mon, Jul 27, 2015 at 11:17 AM, Kyle Huey <[hidden email]> wrote:

> > Is the "lot of work" mostly confined to dom/workers, or do you know of
> other
> > dependencies off the top of your head? Seems like SM TLS would be one.
> Are
> > there others?
>
> The cycle collector comes to mind.
>
> If we want to do serious architectural work around our threading model
> I'd much rather split the main thread into a series of task queues
> than muck around with workers.
>

Yes, that's my ulterior motive here. I'm just trying to figure out if there
are other reasons why we'd also want to fix the direct TLS usage in
SpiderMonkey.

Does anyone have an idea as to whether routing the JS engine's TLS usage
through an embedder-provided callback would be acceptable performance-wise?
If so, I think we should do that (to avoid more dependencies), which has
the added benefit of solving Robin's problem.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Terrence Cole-3
On Mon, Jul 27, 2015 at 11:26 AM, Bobby Holley <[hidden email]>
wrote:

> On Mon, Jul 27, 2015 at 11:17 AM, Kyle Huey <[hidden email]> wrote:
>
> > > Is the "lot of work" mostly confined to dom/workers, or do you know of
> > other
> > > dependencies off the top of your head? Seems like SM TLS would be one.
> > Are
> > > there others?
> >
> > The cycle collector comes to mind.
> >
> > If we want to do serious architectural work around our threading model
> > I'd much rather split the main thread into a series of task queues
> > than muck around with workers.
> >
>
> Yes, that's my ulterior motive here. I'm just trying to figure out if there
> are other reasons why we'd also want to fix the direct TLS usage in
> SpiderMonkey.
>
> Does anyone have an idea as to whether routing the JS engine's TLS usage
> through an embedder-provided callback would be acceptable performance-wise?
>

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.


> 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. In
particular, we need to take a good long introspection about our existing
thread usage first: we currently have a massive pile of TSAN races that are
basically insoluble without major rearchitecting. That said, I think if we
had access to Bobby's new tools in SpiderMonkey, we could probably find
time to make fast progress here.


> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
On Mon, Jul 27, 2015 at 10:48 PM, Terrence Cole <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Robin Ehrlich
In reply to this post by Terrence Cole-3
> 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?

I would love to, but I doubt my employer would be willing to give me the
time.

Sorry.

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Jan de Mooij-3
In reply to this post by Bobby Holley-2
On Tue, Jul 28, 2015 at 9:10 PM, Bobby Holley <[hidden email]> wrote:

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

Hm, during JIT compilation we do a bunch of TLS lookups (this is
TlsJitContext). Fortunately I eliminated most of them in bug 937540, but we
should be careful to avoid regressions. Maybe this is a good reason to
remove TlsJitContext completely.

It seems we could also add APIs to enter/leave a thread, which can then do
the TLS magic?

Jan
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=1188693

My idea is to hoist AbstractThread into MFBT, which will simultaneously let
us teach SpiderMonkey about event loops. Once we do that, we can add TLS
and other functionality to AbstractThread as-needed.

That bug probably isn't actionable until we do bug 1188690. I'll try to
make progress there and see how far I get.

bholley

On Tue, Jul 28, 2015 at 2:02 PM, Jan de Mooij <[hidden email]> wrote:

> On Tue, Jul 28, 2015 at 9:10 PM, Bobby Holley <[hidden email]>
> wrote:
>
>> 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.
>>
>
> Hm, during JIT compilation we do a bunch of TLS lookups (this is
> TlsJitContext). Fortunately I eliminated most of them in bug 937540, but we
> should be careful to avoid regressions. Maybe this is a good reason to
> remove TlsJitContext completely.
>
> It seems we could also add APIs to enter/leave a thread, which can then do
> the TLS magic?
>
> Jan
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

carlos.fangmeier
In reply to this post by Terrence Cole-3
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 <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bobby Holley-2
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, <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

Bill McCloskey
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 <[hidden email]>
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, <[hidden email]> 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 <[hidden email]>
>> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
>
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

dimka.kozlov
In reply to this post by Bobby Holley-2
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 <[hidden email]>
> 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, <[hidden email]> 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 <[hidden email]>
> >> 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
> >> [hidden email]
> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
> >>
> >
> >

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Threading and runtime / context sharing

dimka.kozlov
In reply to this post by Bobby Holley-2
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
> >> [hidden email]
> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine
> >>
> >
> >

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