RFR: 8341334: CDS: Parallel relocation [v9]

[Aleksey Shipilev]

> In Leyden performance investigations, we have figured that `ArchiveRelocationMode=0` is saving 5..7 ms on HelloWorld startup. Mainline defaults to `ARM=1`, _losing_ as much. `ARM=0` was switched to `ARM=1` with [JDK-8294323](https://github.com/openjdk/jdk/commit/be70bc1c58eaec876aa1ab36eacba90b901ac9b8), which was delivered to JDK 17+ in in Apr 2023.
> 
> Profiling shows we spend time mem-faulting the memory loading the RO/RW regions, about 15 MB total. 15 MB in 5ms amounts to >4GB/sec, close to the single-threaded limits. I suspect the impact is larger if we relocate larger Metaspace, e.g. after dumping a CDS archive from a large application. There is little we can do to make the actual relocation part faster: the overwhelming majority of samples is on kernel side.
> 
> This PR implements the infrastructure for fast archive workers, and leverages it to perform parallel core regions relocation. The RW/RO regions this code traverses is large, and we can squeeze more performance by parallelizing it. 
> 
> (I'll put some performance data in the comments)
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - ArchiveWorkers lifecycle: share it globally
 - Add sanity assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21302/files
  - new: https://git.openjdk.org/jdk/pull/21302/files/0a92f8ed..854f6044

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21302&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21302&range=07-08

  Stats: 47 lines in 5 files changed: 24 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21302/head:pull/21302

PR: https://git.openjdk.org/jdk/pull/21302