Hi, If it were at all possible to plan for the web browser to not depend on stopping everything to do a global GC then that would appear a far better plan (assuming the cost is not too high), and can that be done?
I am mindful of the challenges for wasm instances that might implement their own object systems within the linear memory of their instance. These might want to hold references to JS objects, and these references would be integers that can be stored in the linear memory. The challenge of implementing global GC in this context has come up and if there is a practical solution then it may well have a significant impact on the design of the GC. It would not appear to be practical to GC across all wasm instances and JS at the same time in order to implement global GC. Doing so would appear to require the JS GC to call into wasm code to run stages of it's GC and this might not be practical because the resources used for GC might not then be well controlled. For example a wasm task might loop and lock up the entire global web browser process. Thus the design needs to consider how to separate these instances. Cross-process GC might benefit from similar design considerations, allowing processes to run GC independently, and becoming more robust against attacks that compromise one process. Support for cooperation with foreign object stores might be a much more widely useful feature, it could be used to better work with objects across JS instances, across origins, and in the cloud. While the JS engine multi-threading work claims to be a generally useful path forward, the discussion has touched on an number of other important parts of the design and might it need some more thought. Is the reality that "We can only have one GC going on at once" or can we do better? Surely this can not be the case for wasm instances which can implement their own object stores in linear memory, so the perhaps the question should be how (and if) global GC can be supported with a design in which multiple independent object heaps can exist. The focus on cooperative multi-threading is also going to frustrate some useful designs, such as running wasm instances in separate processes for both security and to align their linear memory with the process linear memory for better performance. Perhaps you need to decide if Firefox is to be a high performance web browser for running large wasm apps on challenged devices or alternatively that slower web browser that runs a wasm app plus 50 tabs or frames of ads at the same time but at slower frame rates (if at all due to the lack of resource management) or the eats through batteries faster?? Or has that decision already been made long ago. Regards Douglas Crosher On 01/29/2017 06:50 AM, Brian Hackett 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 > _______________________________________________ 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
