This hits every for-in loop, and is horribly slow. This should be per-thread. JS_LOCK_GC(rt); ok = rt->gcIteratorTable.append(obj); JS_UNLOCK_GC(rt);

iirc this is because workers can migrate from thread to thread. ack!

When that happens, they can move their iterators into an expensive runtime thing and flag them so that we remove from the expensive runtime thing later. (Are threads really that expensive that we can't have one per worker? I guess it's a lot of non-pageable memory on some systems.)

I think we can get rid of this table altogether with some work on iteration. Don't panic! /be

(In reply to comment #1) > iirc this is because workers can migrate from thread to thread. ack! Yes, this is indeed the case. I should have filed a bug to support migration of JSThread to another native thread long time ago. But it is better late than never, bug 554866.

Okay this function was removed, but not the definition in jsgc.h oO

Comment on attachment 576822 [details] [diff] [review] rm I bet nobody will mind... rs=me