RFR: JDK-8318119: Invalid narrow Klass base on aarch64 post 8312018

[Thomas Stuefe]

On Mon, 6 Nov 2023 09:06:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Currently not. Class space is limited to 3Gb, CDS to 1Gb, they are placed adjacent to each other to not surpass 4G.
>
> So what does the word "probably" refer to?

This function attempts to answer "is this address a valid encoding base". Strictly speaking, that question cannot be answered in isolation. The correct question "given a specific Klass range, can a valid encoding scheme be found with this base and any valid shift?".

"Probably" in this context means "This base would work, assuming a future Klass range that starts at the given encoding base and its length does not surpass the maximum encoding range".

This function is used just for one valid use case: verifying the user input for -XX:SharedBaseAddress. That happens at a point where we have not allocated anything yet, so we don't know the future encoding range.

I am really considering removing this function. It is difficult to explain, of not much use, and also slightly wrong since it ignores the base==valid EOR immediate case.

Side note about non-zero immediate + non-zero shift:

The Klass range does not have to start at the encoding base. For encoding base == zero it obviously does not. But also for non-zero encoding bases this could in theory make sense, at least on aarch64 that has no fallback add-base mode.

For example, given a Klass range starting just below 8 GB due to ASLR, this normally would lead to VM exit since such an address is unusable with MOVK, unless it fits EOR mode. But we could use 4GB as encoding base. Since the future Klass range would extend beyond 4GB + 4GB, we would need a non-zero shift that enlarges the encoding range. But then it would work.

We have not done this so far, and there are things to consider (e.g. it would make sense to reserve and protect a single page at encoding base, to get NULL-reference crashes), but it is possible. That is why I am hesitant to hard-code 4GB as encoding range limit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16215#discussion_r1383079914