I was looking at the test running code in js/src last night over a beer. It seems to me the "easy" solution here would be to refactor jit_test.py to use the same test running "framework" as jstests.py. The crazy single process model described in the initial comment could be deferred to a follow-up bug if things aren't fast enough. FWIW, the timings for jit_tests.py on my MBP are as follows: real 18m49.003s user 8m39.230s sys 4m18.158s We have ~13 minutes of CPU time running tests with one core. Assuming we could max out all 4 physical cores plus the 4 hyperthreading threads and yield 25% from hyperthreading, we'd get a nice 5x speedup and would execute tests in about 2.5 minutes! |make check| takes about 30 minutes on builbot machines (this executes jit_tests.py). Parallel jit_test.py execution would shave a *lot* of time off of |make check| and free up build machines to perform more builds.
FYI bug 638219 covers merging those two harnesses.
Also I'd love to get these harnesses packaged up with the rest of the tests and run on the test slaves instead of the build slaves. Then we could fix them to run on mobile as well and gain the ARM test coverage we're currently lacking.