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

[Andrew Haley]

On Mon, 6 Nov 2023 10:28:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 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.

So this function is simply asking a question that cannot be answered
without actually trying it.

> 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.

Please do! If there is to be an answer about whether a base is valid,
let it happen just after a failed attempted allocation.

> 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.

Surely we'd scan upwards until a successful allocation. Why does it
matter where the Klass range starts? Or is the problem that we're
trying hard to honour a -XX: user request, for some reason? What would
be the purpose?

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

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