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 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 Jul 9, 2014, at 2:48 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Jul 9, 2014 at 8:23 AM, smaug sm...@welho.com 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)
- 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 Jul 7, 2014, at 7:11 PM, Robert O'Callahan rob...@ocallahan.org 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:55 PM, Cameron Zwarich zwar...@mozilla.com 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
