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
