On May 7, 2009, at 12:28 PM, Darin Adler wrote:
We consider the current JavaScriptCore protected set to be something deprecated that we’d like to eliminate. We have been steadily decreasing the number of uses of it. All other things being equal, I think it would be good to keep the new mechanism separate.
I'm not sure I would go so far as to say that. For one thing, gc protect is exposed through the C API so we are committed to keeping it if only for that reason.
However, the purpose of Protect.h is different from the aim here. It is supposed to allow keeping a persistent reference to a JavaScript object from native code, for example if you have a C++ heap object that should keep a JS object alive. It's tricky to use, because it has the potential to create unbreakable GC cycles, but I think there are cases where it is useful.
I think two JS objects keeping each other alive across threads/heaps so long as either is rechable (or "active"), is a qualitatively different purpose which deserves a separate mechanism.
Another thing to keep in mind: although JavaScriptCore currently uses a mark/sweep GC, we should design something that can work with a copying GC or other advanced GC algorithms: (a) so it can work with v8 and (b) so we can change JavaScriptCore's garbage collector in the future (this is something we plan to do).
- Maciej _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
