[dev-servo] meeting notes (COW DOM)
> > >- pcwalton: if we can offer things like getComputedStyleAsync, that >could be a bigger win for authors using them. >- jack: that doesn't help us now. > > Apart from what jack said, getComputedStyleAsync might be unusable for a lot of Web authors. Personally I agree with the conclusion to set COW DOM aside. It sounds hard, risky, and not absolutely necessary. pcwalton:in gecko we know that hybrid gc+rc is very difficult, and blink is > similar. CC is still a performance and memory and safety problem. > Difficult, definitely. Performance problem ... now that we have incremental CC and bunch of other optimizations, I feel like it isn't. At least compared to any other viable GC approach, all of which have their own performance pitfalls. Safety problem ... with adequate compiler support, probably not. Proposed C++ reflection features might even be enough for us in Gecko. The general idea of compressing the DOM as you recalc style sounds pretty good! zwarich: JITting will give a huge benefit. > Are there experimental results showing this? Because I haven't seen any yet, and I'd like to :-). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Jul 7, 2014, at 7:11 PM, Robert O'Callahan wrote: > zwarich: JITting will give a huge benefit. > > Are there experimental results showing this? Because I haven't seen any > yet, and I'd like to :-). There is this blog post: https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/ I’m friends with the author and have anecdotal confirmation that the improvements also occur on real web pages. Cameron ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On 7/7/14 7:11 PM, Robert O'Callahan wrote: Difficult, definitely. Performance problem ... now that we have incremental CC and bunch of other optimizations, I feel like it isn't. At least compared to any other viable GC approach, all of which have their own performance pitfalls. Safety problem ... with adequate compiler support, probably not. Proposed C++ reflection features might even be enough for us in Gecko. Yeah, I shouldn't have mentioned safety there, since the fundamental problem is the same whether or not you use CC or GC. You still have to teach the JS engine or the CC about the object graph. We use compiler support for this in Rust, thankfully, eliminating the safety and annoyance-of-writing-trace-hooks problems (via abuse of the serialization module--this should eventually migrate to something better). I guess depending on whether you include leaks as part of safety, you have to be careful to make sure your ForgetSkippable optimizations to throw things out of the purple buffer are correct. I understand that they're necessary, but the purist in me really dislikes wiring application-specific logic into the garbage collector :) Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Tue, Jul 8, 2014 at 2:56 PM, Patrick Walton wrote: > Yeah, I shouldn't have mentioned safety there, since the fundamental > problem is the same whether or not you use CC or GC. You still have to > teach the JS engine or the CC about the object graph. > > We use compiler support for this in Rust, thankfully, eliminating the > safety and annoyance-of-writing-trace-hooks problems (via abuse of the > serialization module--this should eventually migrate to something better). > > I guess depending on whether you include leaks as part of safety, you have > to be careful to make sure your ForgetSkippable optimizations to throw > things out of the purple buffer are correct. I understand that they're > necessary, but the purist in me really dislikes wiring application-specific > logic into the garbage collector :) > The pragmatist in me loves it :-). There's probably a principled way to implement ForgetSkippable in a way that's automatically checkable. Having said all that, I'm not necessarily advocating GC+CC for Servo. It is a hard and complex approach. I'm still a little bit sad that we can't teach Rust to support GC types with a pluggable collector and integrate Spidermonkey's (having taught Spidermonkey's to handle non-JS objects). Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich wrote: > There is this blog post: > > https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/ > > I’m friends with the author and have anecdotal confirmation that the > improvements also occur on real web pages. > Good. I saw that, but wondered if anyone has more science. Rob. -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On 7/7/14 8:07 PM, Robert O'Callahan wrote: The pragmatist in me loves it :-). There's probably a principled way to implement ForgetSkippable in a way that's automatically checkable. Having said all that, I'm not necessarily advocating GC+CC for Servo. It is a hard and complex approach. I'm still a little bit sad that we can't teach Rust to support GC types with a pluggable collector and integrate Spidermonkey's (having taught Spidermonkey's to handle non-JS objects). I believe that's becoming more plausible, actually, now that Azul's patches for late safepoints in LLVM are available. They will need work (for example, they only targeted Java, so Rust enums, which act like C unions, won't work without hacking), but there's a potential path forward here. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
- Original Message - Not to derail this further with a defense of the CC, but... > CC is still a performance and memory and safety problem. At this point, I think the GC is a bigger performance problem. ;) Ok, so it is doing much more stuff than the CC... > Yeah, I shouldn't have mentioned safety there, since the fundamental > problem is the same whether or not you use CC or GC. You still have to > teach the JS engine or the CC about the object graph. Yeah, automatic memory management of C++ is just a pain. The CC is a little nicer because mistakes are (often) only leaks, not arbitrary code execution, like they are with GC. Oilpan seems to be dealing with this problem by using static analysis to check the correctness of their trace methods. I investigated something like that for the CC using Dehydra, but there are a lot of weird traverse methods out there. > We use compiler support for this in Rust, thankfully, eliminating the > safety and annoyance-of-writing-trace-hooks problems (via abuse of the > serialization module--this should eventually migrate to something better). > > I guess depending on whether you include leaks as part of safety, you > have to be careful to make sure your ForgetSkippable optimizations to > throw things out of the purple buffer are correct. Leaks should not be put in the same category as arbitrary code execution, because adversaries are not going to exploit obscure engine bugs to cause leaks. You only need to worry about what people hit in practice. In about 2.5 years of ForgetSkippable optimizations, we've only had a handful of bugs. I was certainly worried about things being removed from the graph that shouldn't have been, but it isn't really a problem in practice. Anyways, I think the main ugliness of the cycle collector is in the integration with the garbage collected heap, and all of the unmark gray stuff. If you can get the perf and implementation costs you need with just one collector, then great. (I think the latter is an overlooked benefit of the CC for Gecko, in that we can mostly just ignore it and it does its thing.) > I understand that they're necessary, but the purist in me really dislikes > wiring > application-specific logic into the garbage collector :) The collector itself just runs per-class callbacks for forget skippable, so I think it isn't too bad all told. The reality is that if you really care about perf, and you are using your collector for a specific program you also control and care about, you are going to need to take advantage of whatever information you can. For instance, the JS allocator is effectively aware of which tab each object is in, so that it can put them in the same zone, because things in the same tab will likely have similar lifetimes. Andrew > > Patrick > > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On 07/08/2014 05:56 AM, Patrick Walton wrote: On 7/7/14 7:11 PM, Robert O'Callahan wrote: Difficult, definitely. Performance problem ... now that we have incremental CC and bunch of other optimizations, I feel like it isn't. At least compared to any other viable GC approach, all of which have their own performance pitfalls. Safety problem ... with adequate compiler support, probably not. Proposed C++ reflection features might even be enough for us in Gecko. Yeah, I shouldn't have mentioned safety there, since the fundamental problem is the same whether or not you use CC or GC. You still have to teach the JS engine or the CC about the object graph. We use compiler support for this in Rust, thankfully, eliminating the safety and annoyance-of-writing-trace-hooks problems (via abuse of the serialization module--this should eventually migrate to something better). I guess depending on whether you include leaks as part of safety, you have to be careful to make sure your ForgetSkippable optimizations to throw things out of the purple buffer are correct. I understand that they're necessary, but the purist in me really dislikes wiring application-specific logic into the garbage collector :) Patrick In general issues with GC handling are security bugs, but in CC they lead to leaks. I could note that max median CC times have been lower than max GC slice times at least since early 2012. CC needs to deal with possible garbage only, GC tends to deal with a lot more objects. I'm not proposing Servo should use gc+cc, but I just don't buy the comment that gc+cc is particularly difficult. Blink doesn't have a collector for refcounted stuff and they are trying to add Oilpan to GC C++ stuff, but at least in the first phase that will not fix the issues where they can't implement complicated APIs where edges go from C++ to JS and back. Implementing such APIs in Gecko is no issue. -Olli ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote: > In general issues with GC handling are security bugs, but in CC they lead > to leaks. > > I could note that max median CC times have been lower than max GC slice > times at least since early 2012. > CC needs to deal with possible garbage only, GC tends to deal with a lot > more objects. > > I'm not proposing Servo should use gc+cc, but I just don't buy the comment > that > gc+cc is particularly difficult. > If you think so, then I think we *should* be considering GC+CC for Servo. Crazy idea: could it even make sense for JS GC to use a traced nursery and a refcounted+CC tenured space? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On 7/8/14 1:23 PM, smaug wrote: In general issues with GC handling are security bugs, but in CC they lead to leaks. This is not the case in Servo, though; we should be foolproof for both. I'm definitely not willing to compromise on memory safety. :) Blink doesn't have a collector for refcounted stuff and they are trying to add Oilpan to GC C++ stuff, but at least in the first phase that will not fix the issues where they can't implement complicated APIs where edges go from C++ to JS and back. Implementing such APIs in Gecko is no issue. I don't think that's a problem in our scheme in Servo either. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On 7/9/14 2:48 PM, Robert O'Callahan wrote: If you think so, then I think we *should* be considering GC+CC for Servo. Crazy idea: could it even make sense for JS GC to use a traced nursery and a refcounted+CC tenured space? This is more or less how RC-immix works, right? http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oopsla-2013.pdf (Note that you need all the precise stack info infrastructure of precise GC in order for RC-immix to work. However, this is starting to look more feasible in Rust, with a fair amount of work.) Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Jul 9, 2014, at 2:48 PM, Robert O'Callahan wrote: > On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote: > >> In general issues with GC handling are security bugs, but in CC they lead >> to leaks. >> >> I could note that max median CC times have been lower than max GC slice >> times at least since early 2012. >> CC needs to deal with possible garbage only, GC tends to deal with a lot >> more objects. >> >> I'm not proposing Servo should use gc+cc, but I just don't buy the comment >> that >> gc+cc is particularly difficult. >> > > If you think so, then I think we *should* be considering GC+CC for Servo. > > Crazy idea: could it even make sense for JS GC to use a traced nursery and > a refcounted+CC tenured space? Would the overhead of ref count modification in JS really be acceptable? I assume it would have to be a deferred RC scheme, which is a reasonable increase in complexity. In theory, the Rust compiler should be able to automatically generate the correct hooks for both tracing and trial deletion, without requiring unsafe code on the part of the user. At that point, we should be able to experiment with different GC schemes without changing much code in Servo itself. Cameron ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Thu, Jul 10, 2014 at 9:53 AM, Patrick Walton wrote: > On 7/8/14 1:23 PM, smaug wrote: > >> In general issues with GC handling are security bugs, but in CC they >> lead to leaks. >> > > This is not the case in Servo, though; we should be foolproof for both. > I'm definitely not willing to compromise on memory safety. :) Yeah but it does mean you can add nifty optimizations like ForgetSkippable without adding to the TCB. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] meeting notes (COW DOM)
On Thu, Jul 10, 2014 at 9:56 AM, Patrick Walton wrote: > On 7/9/14 2:48 PM, Robert O'Callahan wrote: > >> If you think so, then I think we *should* be considering GC+CC for Servo. >> >> Crazy idea: could it even make sense for JS GC to use a traced nursery >> and a refcounted+CC tenured space? >> > > This is more or less how RC-immix works, right? > > http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oopsla-2013.pdf > Thanks for the reference, I hadn't read that. Yes, RC-Immix captures the basic idea, but otherwise what I had in mind is totally different from the RC-Immix design. One reason --- and this applies to just about all academic research on refcounting techniques --- is that it assumes references to any object can be created or destroyed by any thread (because this is true in Java), so reference count updates must be performed using atomic operations and therefore are incredibly expensive. Thus, the entire design is driven by a need to avoid such updates (or completely defer them to a stop-the-world phase). On the other hand, in browsers (and Rust) we can statically distinguish thread-shared objects from thread-local objects; the latter dominate completely and updating their refcounts is almost free. So while academic research on refcounting can give us useful ideas, their performance results and conclusions simply don't apply. The other issue is that RC-Immix performs cycle collection via full tracing of the live objects whereas Gecko CC traces dead objects to find cycles without incoming references. We believe the latter approach is much better, at least for our purposes. This suggests to me that, given RC-Immix can outperform other GCs for Java (and I trust Steve and Kathryn more than the average researcher), for JS and browsers which are much more RC-friendly, simpler RC schemes can probably win big. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
