AArch64: is a compressed class space at 2G a problem?

[Reingruber, Richard]

> >> If the compressed class space is located at 2G then its encoding
> >> base should be zero. We don't care exactly where the space starts,
> >> but we do care very much that its encoding base is 4G-aligned.
> > 
> > Thanks for the feedback! I've created [1] to track this.

> This is bizarre. I'm pretty sure it used to work; maybe something
> else has changed. What we want, in pretty much every case, is an
> unshifted 4G-aligned encoding. Zero-based would be nice.

Looks like you'll get either zerobased with shift or 4G aligned encoding base
without shift. I think it's only since compressed class pointers have become
independent of compressed oops [1] that ccs can be allocated at
HeapBaseMinAddress (2G) resulting in an unscaled encoding. Before ccs was put
behind the compressed oops heap which was fitted at the end of the 4G range if
possible or higher if it didn't fit there. So until [1] you could not get an
unscaled encoding of class pointers. If I'm not mistaken it is like this in 11u.

> Mind you, given that CDS seems to be on by default, I guess any weird options
> won't much be used anyway.

I don't think either it is a real problem. Reading the code can be confusing
though. And AArch64 requires a special case in the new test case for [2].

Richard.

[1] https://bugs.openjdk.java.net/browse/JDK-8241825

[2] https://bugs.openjdk.java.net/browse/JDK-8258576

-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Montag, 21. Dezember 2020 15:19
To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-dev at openjdk.java.net
Subject: Re: AArch64: is a compressed class space at 2G a problem?

On 12/21/20 8:55 AM, Reingruber, Richard wrote:
>> On 12/18/20 4:52 PM, Reingruber, Richard wrote:
>>>
>>> it appears to me that locating the compressed class space (ccs) at 2G is
>>> currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you
>>> agree?
> 
>> If the compressed class space is located at 2G then its encoding
>> base should be zero. We don't care exactly where the space starts,
>> but we do care very much that its encoding base is 4G-aligned.
> 
> Thanks for the feedback! I've created [1] to track this.

This is bizarre. I'm pretty sure it used to work; maybe something
else has changed. What we want, in pretty much every case, is an
unshifted 4G-aligned encoding. Zero-based would be nice.

Mind you, given that CDS seems to be on by default, I guess any
weird options won't much be used anyway.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671