[master] RFR: Load narrowKlass from runtime, decode in generated code

[Aleksey Shipilev]

On Tue, 25 Jan 2022 11:43:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Current implementation of load_klass_runtime() call ensures stable header, loads the narrowKlass from it, decodes it, and returns the Klass* back to generated (interpreter, C1) code. However, C2 wants to load the narrowKlass and use it directly. Let's change current impl to not decode in runtime, but decode in generated code instead, and thus avoid a new entry points for  C2. This doesn't even make generated code larger -- we only need to move the decode_klass() into the common (fast & slow) path.
> 
> The change also contains some exlusions for 32bit builds - narrow_klass() doesn't make sense (and doesn't compile) on x86_32, and thus shouldn't be compiled.
> 
> Testing:
>  - [x] tier1 (x86_64, aarch64)
>  - [x] tier2 (x86_64, aarch64)
>  - [x] tier2 (x86_64, aarch64)

(Tentatively approving to make bots happy)

> However, C2 wants to load the narrowKlass and use it directly.

Really? Why? I thought the universal contract for compressed oops/klasses is "decode on access, never actually deal with compressed forms"?

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1237:

> 1235:   CodeStub* slow_path = new LoadKlassStub(obj, klass);
> 1236:   __ load_klass(obj, klass, null_check_info, slow_path);
> 1237:   __ branch_destination(slow_path->continuation());

Why this one is removed? I'd expect stub's `jmp(continuation)` to get here?

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

Marked as reviewed by shade (Committer).

PR: https://git.openjdk.java.net/lilliput/pull/35