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

Roman Kennke rkennke at openjdk.java.net
Thu Jan 27 11:02:58 UTC 2022


On Thu, 27 Jan 2022 10:44:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> (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"?

AFAIU, a lot of load-klass happens in order to check type, and a common fast-path for this is to compare one type for equality with another (before doing subtype checks, also for primitive types). It is not necessary to decode the nklass for equality check.

> 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?

It has actually been bound twice (to the same effective location), the other one is in c1_LIRAssembler_XXX.cpp:

https://github.com/rkennke/lilliput/blob/ab8ed6331fb4eb2c5eb0e13499178f8ef67dc0f6/src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp#L3546

It is important now to do it in C1_LIRAssembler, because we want the decode_klass() after the common path.

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

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


More information about the lilliput-dev mailing list