RFR: 8265705: aarch64: KlassDecodeMovk mode broken

[Ioi Lam]

On Fri, 14 May 2021 18:04:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Ioi,
> 
> thank you for looking at this.
> 
> > Since we already have an assert to check that the range is less than 4G, can’t we set shift to zero for all platforms? BTW the assert should be changed to a guarantee so it works for product build as well.
> > In the future, if we want to both CDS and >4G CCS, we can revisit this.
> 
> I thought about this, but wanted to limit the patch to aarch64. We are closing in on JDK-17 code freeze and I am snowed in, I don't really want to change Klass pointer encoding now for all platforms.
> 
> Another reason is that as long as we have a shift, I am happy to have platforms which have shift>0 by default; if we set shift to 0 for all platforms on CDS, we don't have any meaningful code paths with shift >0 and it may bitrot.
> 
> If we decide to just do away with the shift altogether, ignoring the potential benefits for Lilliput, then we can do this. And if we manage to make this coding CDS agnostic, this branch will go away and we will do what the CDS=off path does today: use base==0 for pointers < 32g.
> 
> Cheers, Thomas

My reasoning is -- this is platform independent code. If this patch works for aarch64, it must also work for other platforms. Conversely, If it doesn't work for any other platform, why do we believe it would work on aarch64?

Since we test other platforms much more than aarch64, I think the best way to ensure that the patch works is to also turn it on for all platforms.

JDK 17 repo branch happens next month, but we still have a couple of months afterwards for bug fixes. I think we have enough time to handle any problems that may happen.

Lilliput is not going to happen for a while, and we can handle it when the time comes. (It's not like the existing hard-coded shift of 3 is going to be much more compatible with Liliput than 0).

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

PR: https://git.openjdk.java.net/jdk/pull/3968