P4
Since JDK-8294323, we use ArchiveRelocationMode to shuffle the eventual location of mapped CDS archives. This is awkward, since ArchiveRelocationMode=1 now covers two meanings:
- "randomize CDS location"
- "test fallback relocation after an initial failed mapping attempt at the preferred base".
And the JVM does not know which one the user means.
So, we always map, then unmap, then remap again. That increases the number of system calls at startup (each archive mapping needs a number of mmap calls) and is needlessly confusing.
For the Non-CDS case, we already have a switch to randomize class space location (RandomizeClassSpaceLocation).
I propose to have a generic switch, RandomizeKlassRangeLocation, which should cover both class space and CDS. It would, therefore, replace RandomizeClassSpaceLocation and complement ArchiveRelocationMode. ArchiveRelocationMode would go back to being a testing switch only, and RandomizeKlassRangeLocation would allow us to clearly communicate the intent to randomize CDS location right from the get-go.
- "randomize CDS location"
- "test fallback relocation after an initial failed mapping attempt at the preferred base".
And the JVM does not know which one the user means.
So, we always map, then unmap, then remap again. That increases the number of system calls at startup (each archive mapping needs a number of mmap calls) and is needlessly confusing.
For the Non-CDS case, we already have a switch to randomize class space location (RandomizeClassSpaceLocation).
I propose to have a generic switch, RandomizeKlassRangeLocation, which should cover both class space and CDS. It would, therefore, replace RandomizeClassSpaceLocation and complement ArchiveRelocationMode. ArchiveRelocationMode would go back to being a testing switch only, and RandomizeKlassRangeLocation would allow us to clearly communicate the intent to randomize CDS location right from the get-go.