Forwarding to the list, this got bounced by @googlegroups address (grumble)
----- Original Message ----- > From: "Brian Hackett" <bhack...@mozilla.com> > To: "Steve Fink" <sf...@mozilla.com> > Cc: "mozilla dev tech js-engine internals" > <mozilla.dev.tech.js-engine.intern...@googlegroups.com>, > tc...@mozilla.com, bi...@mozilla.com, "Dave Mandelin" > <dmande...@mozilla.com>, "Bill McCloskey" > <wmcclos...@mozilla.com> > Sent: Friday, July 13, 2012 1:30:18 PM > Subject: Re: Approach for adapting SpiderMonkey to moving GC > > There are a lot of legitimate uses of unrooted pointers and values > within the engine, and I'd rather not spray Unrooted<T> around > wantonly, it will just make perfectly fine code much less readable > (and, as you point out, doesn't give any new guarantees). My strong > preference is to wait and see how things look after some (or a lot) > of fuzzing. If we do end up wanting stronger guarantees, we can get > them, but it will need to be done using compiler extensions / static > analysis. Using features of C++ (i.e. require rooting everywhere, > as we're going to do for API clients) will not give us the needed > flexibility to be performant. > > I'm pretty confused by the hashtable talk. We can already rekey > hashtables in which GC thing pointers are used as keys, and the GC > will already be traversing these tables in order to do its job. So > isn't this just an issue of auditing our hashtables and making sure > they are rekeyed appropriately? > > Brian > > ----- Original Message ----- > > From: "Steve Fink" <sf...@mozilla.com> > > To: "Bill McCloskey" <wmcclos...@mozilla.com> > > Cc: "mozilla dev tech js-engine internals" > > <mozilla.dev.tech.js-engine.intern...@googlegroups.com>, > > tc...@mozilla.com, bi...@mozilla.com, jo...@mozilla.com, "Brian > > Hackett" <bhack...@mozilla.com>, "Dave Mandelin" > > <dmande...@mozilla.com> > > Sent: Friday, July 13, 2012 11:44:32 AM > > Subject: Re: Approach for adapting SpiderMonkey to moving GC > > > > My current leaning: > > > > ... > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals