Implement persistent workers for parallel jit-tests
Categories
(Core :: JavaScript Engine, enhancement, P5)
Tracking
()
People
(Reporter: decoder, Unassigned)
References
Details
(Whiteboard: [capacity][buildfaster:1])
|
Assignee | |
Updated•11 years ago
|
|
||
Comment 1•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
|
||
Comment 2•2 years ago
|
||
Pinging Nicolas as he's the last person who's looked at this IMO: Is this still a real thing, or should we just close as FIXED (or INCOMPLETE is fine too)
|
||
Comment 3•2 years ago
|
||
This bug is an improvement over how our test suite works. It suggested spawning a single process in which test case executions are delegated.
Recalling multiple discussion across the decades, while this sounds appealing, this only removes the cost of spawning / closing processes from the system side, but does not skip over the re-initialization of the global as the test case behavior might change if we were to reuse it. Spawning processes is only costly on Windows platform, but not on Mac nor Linux.
The problem of spawning process has previously been fixed on Android, and the cost of spawning processes has been reduced using a different approach of caching the unconditional work in a file which is decoded by all other test cases executions.
Thus, I think with these learning these past years is that it would be more beneficial for us to provide caching of the initialization over reusing existing processes which might be a source of non-determinism when reproducing test cases.
Also, if this issue is related to fuzzing, then we now have a mechanism which is doing exactly this recovery mechanism, in a way which is dedicated to fuzzing. (see https://searchfox.org/mozilla-central/source/js/src/fuzz-tests/README )
Description
•