RFR: JDK-8261552: s390: MacroAssembler::encode_klass_not_null() may produce wrong results for non-zero values of narrow klass base
Lutz Schmidt
lucy at openjdk.java.net
Mon Feb 22 07:14:41 UTC 2021
On Mon, 22 Feb 2021 06:28:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> I don't see how you want to overcome the 32-bit limit for compressed pointers. This whole "compression" thing is based on the "trick" to store an offset instead of the full address. Depending on the object alignment requirement, this affords you 32 GB (8-byte alignment) or 64 GB (16-byte alignment) of addressable (or should I say offset-able) space. That's quite a bit.
>>
>> You use pointer compression to save space, and for nothing else. Space savings have to be so significant that they outweigh the added effort for encoding and decoding. With just some shift and add, the effort is limited, though noticeable. If you would make compressed pointers 40 bits wide (5 bytes), encoding and decoding would impose more effort. What's even worse, you then would have entities with a size not native to any processor. Just imagine you have to atomically store such a value.
>>
>> I my opinion, wider compressed pointers will have to wait until we have 128-bit pointers.
>>
>> Back to code:
>> In the code suggested above, you could make use of the Metaspace::class_space_end() function. If the class space end address, shifted right, fits into 32 bit, need_zero_extend may remain false. Your choice.
>
> You misunderstand me. My point was not to make narrow pointers larger than 32bit, but use the full encodable range. The encodable range is 32g atm. But we artificially limit the range to 3G (CompressedClassSpaceSize is capped at that value).
>
> I thought your proposal was based upon the assumption that the highest *uncompressed* offset into class space can be not larger than 4G. But looking at your proposal again, I see you moved the shift up before the add, so it should probably work.
So it was mutual misunderstanding. Good to have that resolved.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2595
More information about the hotspot-dev
mailing list