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

[Andrew Haley]

On Mon, 6 Nov 2023 15:17:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > Why not do the optimized (for AArch64) stuff before trying the immediate + shift?
> > 
> > For AArch64, the optimum is zero base, no shift, then immediate base, no shift, then shift, and last of all immediate + shift.
> 
> Wait, immediate + shift=0 before no immediate=0 + shift? Why? Looking at https://dougallj.github.io/applecpu/firestorm-int.html , both movk and lsl need the same number of cycles. Why would movk be better than lsl?

I agree, good point. Those are equal on modern AArch64 CPUs. LSL (immediate) is an alias for UBFM, and I had a vague memory that was slower, but I don't think that's so now, if ever it was.

> The reason I ask is that this would mean switching up the order of things I do in Metaspace::reserve_address_space_for_compressed_classes. That function attempts to do the best for all platforms, and all other platforms prefer zero immediate + shift. It would mean even more ifdefs than we have before.

I see.

> (the best way would be to move this function into CPU specific files. We would have some duplication, but at least every CPU can then decide how to layout memory, and the comments would not have to be so darn vague. 

Ah, it's not just me, then.

I think you at least have to say what you think might fail, rather than we can say no more. Something like "If the address space is already highly allocated we might fail." 

> But last time I attempted that I ran into objections from reviewers).

Shame. This is very CPU specific.

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

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