[joelgwebber]

To be precise, Blink is moving to a GC for stability (including avoiding leaks), but I don't believe it's for security -- the renderer remains sandboxed because it's effectively impossible to secure such a huge pile of C++ code. This presentation (which assumes a lot of familiarity with the WebKit/Blink smart pointers) goes into some interesting detail: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...

It includes particularly intriguing bits like "You can remove all on-stack RefPtr<X>'s. This is the biggest reason why Oilpan performs better than the current reference counting." I don't know whether that always holds true -- as of the middle of last year, I heard that they'd gotten to the point where most things perform roughly at parity, some worse, and some better. Keep in mind that this is an opt-in system -- if you don't use the smart pointers the GC knows about, it will ignore them (IOW, it's not some crazy conservative beast like the C++ Boehm collector). Also, my understanding is that, the vast majority of the time, Oilpan only runs when the event loop goes idle, which makes perfect sense for a browser, and has an obvious correlate in a game's simulation/rendering loop. I think they only walk the stack looking for pointers in rare cases.

It's not hard to imagine a hybrid world where you opt-in to GC'd pointers, but are free to use different allocators for performance-sensitive bits. This smells a little like Rust, but without the need to satisfy the lifetime checker thing.

Thanks for the pointer on libco. I'll definitely have a look at that. I've not written much C++ (apart from Chrome and a few odds and ends while at Google) in a long time, so it's quite probable I've missed some significant improvements on that front.