[master] RFR: Prepare for smaller-than-22-bit class pointers

[Thomas Stuefe]

On Sat, 27 Apr 2024 07:43:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This PR prepares using arbitrary klass pointer sizes (e.g. 16). It cleans up a few places and corrects comments.
> 
> The changes in detail:
> 
> - exposes a new function `CompressedKlassPointers::max_encoding_range_size()` that returns the maximum possible size of the encoding range given the current nKlass geometry (e.g. 16 bit klass pointers with a max. shift of 10 bits can encode 64MB of class space). 
> 
> - In Metaspace::ergo_initialize(), where we ergo-adjust the CompressedClassSpaceSize, the maximum possible encoding range size flows into this adjustment now. We also print clearer warnings in case the user specifies CCS size explicitly, and we override that decision.
> 
> - removed any hard-wiredness of a "max class space size/encoding range size of 4GB" since with smaller geometries that does not hold true anymore. Instead, we now use `CompressedKlassPointers::max_encoding_range_size()`.
> 
> - made the requirements on klass_alignment_in_bytes clearer when setting up class space
> 
> - removed remnant code (TinyClassPointerShift) left over from development
> 
> 
> Note: One still unsolved problem—unsolved in Lilliput as well as upstream—is to correctly limit the compressed class space size in the presence of CDS. Upstream "solves" this by capping CCS size at 3GB, which leaves 1GB for CDS archives. There is no solution if CDS would ever exceed this limit,  and it's a waste of space for CCS. 
> 
> In Lilliput, if we limit the class pointer size such that we drastically reduce the klass encoding range size, we need to be better at splitting that klass encoding range between CDS and class space. For example, we could map CDS and then use the remaining space completely for class space. But that would require more serious reshuffling for initialization code, and CDS setup is horrendously complex.
> 
> For this patch, if one wants to reduce class pointer size, one may have to disable CDS to run.
> 
> Tested: Mac m1, fastdebug, with 32, 22 and 16 bit class pointers. GHAs in process.

All test errors stem from the fact that we call the JVM with a very small MaxMetaspaceSize, and the CCS size - which is set to 80% of MaxMetaspaceSize - then is down-aligned by root chunk size (16MB). That causes CCS size to be 0 now.

Before, we were aligning CCS size by root chunk size. With Lilliput, that is a bug, since we may have a smaller-than-4GB encoding range, which in turn means that CCS sticks its feet out of the encoding range cover. Upstream this bug is only theoretical since CCS is limited to 3GB and encoding range is 4GB.

Okay, I now just require the max encoding range to be at least the size of a root chunk (16 MB) and otherwise revert the behavior to before, meaning we round up CCS size to root chunk size. That means that we cannot have < 14 bit  nKlass pointers for now with a 10 bit shift. I think we can live with that.

Mac x64 errors unrelated.

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

PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2082375585
PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2082402196
PR Comment: https://git.openjdk.org/lilliput/pull/172#issuecomment-2084758295