[master] RFR: Load narrowKlass from header, AArch64 assembler implementation [v7]

Roman Kennke rkennke at openjdk.java.net
Wed Feb 2 14:58:45 UTC 2022


On Tue, 1 Feb 2022 13:15:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This implements MacroAssembler::load_klass() to load the (narrow)Klass* from object header. Just like the x86_64 implementation, it checks whether it can take the fast path (object unlocked -> load from upper 32bits of header), or else calls the runtime to get a stable header and load from that.
>> 
>> It adds a runtime call stub, which will also be used in the C2 implementation. It also adds nklass_offset_in_bytes() which will also be used in C2 impl. The part in generate_verify_oop() is a little nasty, I added a comment that explains what's going on.
>> 
>> Testing:
>>  - [x] tier1 (aarch64)
>>  - [x] tier2 (aarch64)
>>  - [x] tier3 (aarch64)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup remaining uses of klass_offset_in_bytes in aarch64

> > Thanks! I believe the trouble is that load_klass() is used in some C1 generated code paths, and C1 register allocator doesn't ignore rscratch1 and rscratch2. I may be wrong, though.
> 
> I hope you are! - None of the register allocators can touch the scratch registers. Lots of hand-written code depends on that.


> > Thanks! I believe the trouble is that load_klass() is used in some C1 generated code paths, and C1 register allocator doesn't ignore rscratch1 and rscratch2. I may be wrong, though.
> 
> I hope you are! - None of the register allocators can touch the scratch registers. Lots of hand-written code depends on that.

I had a look at the C1 register allocator, and could verify that I was wrong.

Thanks for reviewing and helping!

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

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


More information about the lilliput-dev mailing list