-
Enhancement
-
Resolution: Unresolved
-
P4
-
17, 21, 25, 26
Current CTW runner has troubling internal parallelism. There are at least these troubles:
1. The thread pool that drives compilation requests is small, driven by CICompilerCount. We want that pool to be larger, so that we have _more_ requests than there are compiler threads, so that compilers always have work to do.
2. The thread pool runs with caller-runs policy, which means an accidental spike in compile queue would stop it from scheduling more work, hindering parallelism.
3. The clinit compilations are not done in parallel. This makes situations like (2) even more awkward, as long clinit compilation for a particular class may tank the parallelism completely. This is often seen in java.base CTW runs.
1. The thread pool that drives compilation requests is small, driven by CICompilerCount. We want that pool to be larger, so that we have _more_ requests than there are compiler threads, so that compilers always have work to do.
2. The thread pool runs with caller-runs policy, which means an accidental spike in compile queue would stop it from scheduling more work, hindering parallelism.
3. The clinit compilations are not done in parallel. This makes situations like (2) even more awkward, as long clinit compilation for a particular class may tank the parallelism completely. This is often seen in java.base CTW runs.