On Fri, Jan 27, 2017 at 4:55 PM, Steve Fink <sf...@mozilla.com> wrote: > Let me see if I'm understanding this correctly. > > The previous setup we had, that was largely considered a disaster, also had > JSContexts on different threads. The big difference here is that the zone > groups do not need to share data for the most part. So we don't need the > fine-grained locking like we used to have. We can keep the vast majority of > shared data on the JSRuntime, so it is clear what can be shared. And call > stacks should never have more than one zone group, plus the system zone > group. Is that all correct?
Yes, this is correct. > Where is this not true? As in, where are the expected hard parts? The hard parts mainly revolve around the GC. We can only have one GC going on at once, and we need to make sure that we are both able to maintain a coherent, race free GC state and that we can deal with tricky situations like canceling/finishing an incremental GC in one zone group (that might not be owned by the current thread) in order to perform an urgent GC on another zone group. > How does the system zone group work? What happens in cases where you do want > to do things across zone groups, eg memory accounting? Well, from the perspective of the JS engine I think the semantics of the system zone group can be largely abstracted. It could be just another zone group, and JS could just call a hook whenever a context tries to move from one zone group into another that takes a lock or throws an exception or something. The only real requirement we have is that a context cannot relinquish control of a zone group while it still has frames or roots from that group on the stack. This is required to preserve run-to-completion semantics, and also for GC tracing (a thread that initiates a GC should only have to trace its own stack, and not that of other threads; this isn't as much of a concern with cooperative scheduling, though). Things like memory reporting should fit in with the GC tracing API changes I mentioned earlier. Callers who want information about the memory used by some zone group will need to obtain exclusive access to those groups before using the APIs. Ideally no one will ever need to access more than one group (plus the system group) at a time; memory reporting can be done by just visiting each group separately and tabulating its contents. If some use case needs to access an arbitrary set of zone groups then it could still be done, but would need cooperation on the DOM side to make sure there is no possibility of deadlock (i.e. that no other threads are executing similar tasks). Brian _______________________________________________ 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
