Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Steve Fink
(apologies if you receive this twice; trying to fix 2 sending failures) My current leaning: - Use the current scheme of Rooted, MutableHandle, and Handle - Add in an Unrooted - Eliminate pretty much all bare pointers from the engine (except in some of the GC code) - Convert all member functio

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Brendan Eich
Steve Fink wrote: Another hole is when we use the pointer value to compute a hash code, which we unfortunately do pretty often. For JSObjects, at least, it would be really nice if we had an identity value to use instead. dmandelin and I talked about this, and initially I assumed this would requir

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Jeff Walden
On 07/13/2012 11:28 AM, Brendan Eich wrote: > Steve Fink wrote: >> Another hole is when we use the pointer value to compute a hash code, >> which we unfortunately do pretty often. For JSObjects, at least, it >> would be really nice if we had an identity value to use instead. >> dmandelin and I talk

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Brendan Eich
Jeff Walden wrote: On 07/13/2012 11:28 AM, Brendan Eich wrote: Steve Fink wrote: Another hole is when we use the pointer value to compute a hash code, which we unfortunately do pretty often. For JSObjects, at least, it would be really nice if we had an identity value to use instead. dmandelin a

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Brian Hackett
Forwarding to the list, this got bounced by @googlegroups address (grumble) - Original Message - > From: "Brian Hackett" > To: "Steve Fink" > Cc: "mozilla dev tech js-engine internals" > , > tc...@mozilla.com, bi...@mozilla.com, "Dave Mandelin" > , "Bill McCloskey" > > Sent: Friday, J

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Brendan Eich
Brian Hackett wrote: 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

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Steve Fink
On Fri 13 Jul 2012 12:37:10 PM PDT, Brian Hackett wrote: > Forwarding to the list, this got bounced by @googlegroups address (grumble) > > - Original Message - >> From: "Brian Hackett" >> To: "Steve Fink" >> Cc: "mozilla dev tech js-engine internals" >> , >> tc...@mozilla.com, bi...@mozi

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Dave Mandelin
Bill sent this out, but it seems not to have reached the newsgroup, so pasting it here. (By the way, to avoid such things, I just post through groups.google.com.) So Bill said: I didn't respond to Dave's email right away because I wasn't sure how I felt, and I had a lot of questions about how r

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Jeff Walden
On 07/13/2012 12:18 PM, Brendan Eich wrote: > Because many objects (most in popular workloads for which V8's nursery > collection > wins) are short-lived and by definition won't be moved, so they should not be > taxed by an optional private-keyed identity property. > > Don't walk into known perfo

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread Dave Mandelin
On Friday, July 13, 2012 1:41:00 PM UTC-7, Dave Mandelin wrote: > Bill sent this out, but it seems not to have reached the newsgroup, so > pasting it here. (By the way, to avoid such things, I just post through > groups.google.com.) > > So Bill said: > > I didn't respond to Dave's email right a

Re: [JS-internals] Approach for adapting SpiderMonkey to moving GC

2012-07-13 Thread David Anderson
On 07/13/2012 02:47 PM, Dave Mandelin wrote: > And I don't want to bikeshed on stuff if it is not important, but > 'Rooted' still sounds weird to me. It sounds like a name that > would be used in a parameter to indicate that something is rooted > (but we call that Handle, which is fine, and better)