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
