RFR: 8323273: AArch64: Strengthen CompressedClassPointers initialization check for base

[Yude Lin]

On Tue, 16 Jan 2024 02:41:40 GMT, Yude Lin <duke at openjdk.org> wrote:

> Summary:
> Add a platform-dependent check for CompressedClassSpaceBaseAddress;
> Remove the "reserve anywhere" attempt after the initial mapping attempt failed---this is rarely used and will likely fail anyway, because the accepted mapping is very restricted on aarch64;
> Additional assertions after initialization.
> 
> Passed hotspot/jtreg/:tier1 on fastdebug

I think the strangest thing to me is if the reservation fails (admittedly very rare if ever), the code choose to fire the error at stub generation. It's rather random---Maybe in another day, when initialization code changes and something that also decodes klass moves ahead of stub generation, the error could happen there. We would need time to associate all the appearances of the error with the root cause of the error. So why not add assertions right after reservation?

You might argue that this nearly never happens in product and not worth the complication. I currently cannot argue with that because I haven't observe one myself, and I will drop the patch. But note that a single assertion would help. Perhaps consider adding one in incoming class-space refactoring?

> .. strange return code contract of eor_compatible_klass_encoding.

It returns the number of bits allowed to encode a klass. So 0 means there is no space left for klass encoding. Thanks for the feedbacks though. I understand the frustration of seeing those platform dependent code in shared code. I'll try not to write anything like that again.

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

PR Comment: https://git.openjdk.org/jdk/pull/17437#issuecomment-1952166067