[master] RFR: JDK-8325104: Lilliput: Shrink Classpointers [v3]

[Thomas Stuefe]

On Mon, 25 Mar 2024 16:27:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Roman feedback - small stuff
>>  - Merge branch 'master' into Smaller-ClassPointers
>>  - revert COH archive generation
>>  - Remove files that accidentally slipped in
>>  - Merge branch 'master' into Smaller-ClassPointers
>>  - Merge
>>  - Merge commit 'c1281e6b45ed167df69d29a6039d81854c145ae6~1' into Smaller-ClassPointers
>>  - Fix Typo
>>  - Better CDS arch generation
>>  - Fix error in COH archive generation
>>  - ... and 10 more: https://git.openjdk.org/lilliput/compare/b2fcfb73...1260f2d6
>
> src/hotspot/share/oops/oop.hpp line 345:
> 
>> 343:       constexpr int load_shift = markWord::klass_load_shift;
>> 344:       STATIC_ASSERT(load_shift % 8 == 0);
>> 345:       return mark_offset_in_bytes() + load_shift / 8;
> 
> Isn't this broken for big-endian machines? The follow-up question then is, should we really be reading the klass pointer with 32-bit loads? If we load the entire 64-bit "object header" and then shift with `klass_shift`, we wouldn't have to think about endianess, right? Do we keep the 32-bit load because we don't want to mess with C2?

There was a technical problem when I developed the patch, which is that a klass_offset_in_bytes needed to be != mark_offset_in_bytes. See e.g. `Compile::flatten_alias_type`, but I believe there had been other places.

Then, a 32-bit load can possibly be encoded with fewer bytes, no? I am not sure if it would be faster beyond that distinction, however.

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

PR Review Comment: https://git.openjdk.org/lilliput/pull/128#discussion_r1539029186