RFR: 8341334: CDS: Parallel relocation [v6]

[Aleksey Shipilev]

On Tue, 5 Nov 2024 14:57:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>   * You currently start the threads unconditionally whenever a FileMapInfo is created. That means we also start them when dumping. Can this be avoided?

I think we should collectively decide not to care all that much about minor overheads on dump path :) Leyden would make dump path even slower, and attempts to save a few cycles with not starting the worker threads would likely be a wash.

> * if we load both dynamic archive and static archive, thread group startup and shutdown happens twice?

Yes, I think so. I think this is even worse: if two `FileInfoMap`-s are open concurrently for dynamic and static archives, we run with both pools, dang. The placement of `ArchiveWorkers` in `FileInfoMap` was alas the most convenient. I can rewrite this to make `ArchiveWorkers` globally accessible, let me see..

> * On machines < 12 cores, we run with just one worker thread. Should we then not just do the work inside the master thread itself? 

Yes, we should. This was an overlook in my previous implementation. Now we handle the "non-parallel" mode explicitly, and that avoids going into workers completely.
 
> * Should we limit the number of workers on machines with many cores?

My experiments with thread counts shows that taking 1/N CPUs: a) on low-thread configs robs us of available parallelism, as we select too few workers; b) on high-thread configs overwhelms the system, as we select too many workers. So I redid the worker sizing logic to be more eager in lower-count region and more conservative in high-thread-count region. As we are now growing the number of workers very slowly, so I think we do not need a high cap anymore.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21302#issuecomment-2459484727