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

Reply via email to