Hi Brian, Thank you for the detailed answer. So if I understand correctly, long-term this should all be as good as or better than what we have now, and short- to medium-term it should be possible to have *either* a system zone group with potentially circular references to arbitrary content zone groups - which is probably a requirement for Firefox - *or* multiple concurrent GCs?
If that sounds about right, then it'd be great to give embeddings the ability to choose between these options. Alternatively, and even better, perhaps zone groups could be configured to be completely standalone or allow access to and by the system zone group. That'd allow DOM Workers to keep the current behavior of having entirely independent GCs. Jack brought this up as a potential issue for Servo, but since Servo doesn't need a system zone group, we should be fine with either of these solutions. Thanks, Till On Sat, Jan 28, 2017 at 8:50 PM, Brian Hackett <bhackett1...@gmail.com> wrote: > Hi, these are all good points. I'd like to be able to have multiple > GCs happening at once, but the design constraints involved aren't > clear enough to me to determine what such a thing would end up looking > like. Having one GC at a time is easier to do, and it's all that will > initially be required for cooperative multithreading. > > A lot here hinges on the nature of cross-zone-group edges. Content > zone groups won't point to other content zone groups, but there could > be pointers between a system zone group (basically chrome code that > runs in the content process) and the content zone group. If there are > pointers in both directions between a system zone group and content > zone group, we can get cycles which necessitate collecting from both > zone groups at once. If an object in the system zone group > participates in cycles involving objects in each content zone group > then we would need to collect from all zone groups to collect that > object. > > It would be best if it is never necessary to collect from more than > one zone group; then each zone group could have its own GC happening > independently. Doing this would I think require either (a) not having > a system zone group and just putting chrome code in content zone > groups, with no edges between different zone groups, (b) not having > edges in one direction or the other between the zone groups, or (c) > treating edges in one of the directions as weak. I don't know enough > about how things will end up working to say whether any of these are > possible. > > If we *do* end up needing to collect from multiple zone groups at > once, I think we could still have multiple GCs happening > simultaneously --- the groups being collected by a GC could share a > heap structure with their GC state, or the GC state would be on the > stack of a helper thread which is managing the collection. > > Minor GCs are a simpler matter. Since they are zone group local I > don't think it will be hard to allow zone groups to perform minor GCs > of their nurseries independent of the GC behavior in other groups. > > Brian > > On Sat, Jan 28, 2017 at 11:27 AM, Till Schneidereit > <t...@tillschneidereit.net> wrote: > > On Sat, Jan 28, 2017 at 3:26 PM, Brian Hackett <bhackett1...@gmail.com> > > wrote: > >> > >> 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. > > > > > > Will there really be no way to have multiple GCs happening at the same > time? > > And does that include minor GCs? > > > > If so, that seems problematic to me for three reasons: > > > > - DOM Workers can now cause websites to jank through heavy allocations. > > Because that's not the case in any browser right now, moving operations > to > > workers is a way to reduce jank that authors are using, so it seems > likely > > to cause user-visible regressions. > > > > - My understanding is that Quantum DOM (in the preemptively-scheduling > > end-state) aims to get us many of the performance and responsiveness > > benefits of using many content processes without the memory overhead. > Having > > one window's allocations interfere with the responsiveness of others > would > > leave us in a worse position compared to process separation. > > > > - Servo is using a setup that includes many runtimes (roughly one per > zone > > group, other terminology notwithstanding) to achieve goals similar to > > Quantum DOM. I can't find it right now, but I think we even have a demo > > showing smooth animation in one frame while another frame is suffering > from > > GC jank. > > > > None of these are problems as long as GC doesn't actually jank script > > execution. At least if minor GCs are also included, it seems quite likely > > that it will: as you alluded to, a long-ish incremental GC would need to > be > > finished non-incrementally if we run out of nursery space at any point > > during its execution. > > > > > > Till > _______________________________________________ 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
