+++ This bug was initially created as a clone of Bug #605662 +++ If we make sure we don't touch any other compartments while we GC a compartment, we can do so concurrently and in the background while the rest of the application continues.

Post 2.0

A sample app that would benefit (where we are currently losing to WebKit because our workers spend 1/2 their time blocking on GC) is the one attached to bug 617569.

Just wondering when should an em-bedder expect this to land? Thanks.

There isn't any work being done in this direction right now.

Ok. What direction is the engine taking these days? I'm sorta waiting for something to shake out. How can I run 500 threads with 500 runtimes? Any direction would be appreciated.

(In reply to Mike Moening from comment #5) > Ok. What direction is the engine taking these days? > I'm sorta waiting for something to shake out. How can I run 500 threads > with 500 runtimes? Any direction would be appreciated. The stuff related to concurrent programming that's going on right now is: - Remove old multithreading features and simplify the engine - Experiment and think about concurrent models (e.g., web workers, River Trail) For your 500 threads, we'd need something new, possibly as simple as making runtimes cheap enough so you can have 500, or possibly an entirely new model--depends on how you're actually using those threads. I'd like to talk about this more, but probably not in this bug--want to post something in the mailing list?