RFR: 8236847: CDS archive with 4K alignment unusable on machines with 64k pages [v2]

erik.joelsson at oracle.com erik.joelsson at oracle.com
Mon Mar 1 13:51:17 UTC 2021


On 2021-02-28 06:11, Andrew Haley wrote:
> On Fri, 26 Feb 2021 18:28:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>
>> Before this fix, the alignment is defaulting to that of the build host. We would like to provide a way to produce a JDK distribution, with a pre generated CDS archive, where the alignment has the highest known value of any target host for maximum compatibility. The currently known such values are 64K for Linux and 16K for Mac. If we aren't going to allow the user (builder of OpenJDK) the free choice of any alignment anyway, would it make sense to limit the choice between something more abstract like "host" and "compatible" instead of listing explicit numbers?
>   That's problematic because it assumes we know all of the possible alignments.  At the present time we think that 64 is the largest we'll ever encounter, but IMO that isn't a great way to think about things. It would be very nice indeed if we didn't have to edit OpenJDK for the next page size. I guess 4k, 16k, and 64k are all we'll ever see, but I wouldn't bet the farm on it.
>
>> Finally there is the question of if "host" or "compatible" should be the default. I see good arguments for both sides, as long as there is an option to switch between the too that isn't too cryptic to understand.
> I would have thought that "host" made the most sense, but I don't really mind.

The latest patch keeps the default as it is now, so essentially "host". 
The parameter is now on the form enable/disable, which I think makes 
sense. I also think that if we ever encounter the situation where we 
need to be more flexible, we can extend the parameter to also take a 
numerical argument (e.g. --enable-compatible-cds-alignment=128k), but 
until we see that need, I don't think we need to complicate things 
unnecessarily.

/Erik

> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2651



More information about the build-dev mailing list