Closed Bug 829412 Opened 11 years ago Closed 1 year ago

Implement persistent workers for parallel jit-tests

Categories

(Core :: JavaScript Engine, enhancement, P5)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [capacity][buildfaster:1])

The code we added bug 827960 for running jit-tests in parallel isn't as efficient as it could be. As gps pointed out, we should have persistent worker processes rather than spawning a new one for every test.
Assignee: general → nobody
QA Whiteboard: qa-not-actionable

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.

Severity: major → --

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)

Flags: needinfo?(nicolas.b.pierron)

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 )

Blocks: sm-meta
Severity: -- → N/A
Status: NEW → RESOLVED
Type: defect → enhancement
Closed: 1 year ago
Flags: needinfo?(nicolas.b.pierron)
Priority: -- → P5
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.