[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