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
