RFR: 8297036: Generalize C2 stub mechanism [v3]

Xiaolin Zheng xlinzheng at openjdk.org
Tue Nov 29 12:59:22 UTC 2022


On Tue, 29 Nov 2022 12:02:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, we have two implementations of out-of-line stubs in C2, one for safepoint poll stubs (C2SafepointPollStubTable in output.hpp) and another for nmmethod entry barriers (C2EntryBarrierStubTable in output.hpp). I will need a few more for Lilliput: One for checking lock-stack size in method prologue, one for handling lock failures (both for fast-locking), and another one for load-klass slow-path. It would be good to generalize the mechanism and consolidate the existing uses on the new general mechanism.
>> 
>> Testing:
>>  - [x] tier1 (x86_64, x86_32, aarch64)
>>  - [x] tier2 (x86_64, x86_32, aarch64)
>>  - [x] tier3 (x86_64, x86_32, aarch64)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AArch64 parts

Thank you for the updates, Roman! I am working on the RISC-V part and testing the values now, and I think the current version is nice enough ;-).

> However, we do call maybe_expand_to_ensure_remaining() before align(), that happens in C2CodeStubList::emit() before each stub gets emitted.

But I think the `align()` is a different story - I guess there shall be another fix [1] independently; it appears to me that there is no such `align()` thing in `C2CodeStubList::emit()` :-) In my opinion, it is another issue if I didn't miss something.

I am still natively compiling a RISC-V fastdebug build using QEMU - it is slow but already fast enough compared to natively building on a physical board - and may need about one hour for me to come back to you.

[1] https://github.com/zhengxiaolinX/jdk/commit/0c031a78742d10c84a7cf2f3ec3a823351bb9876

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

PR: https://git.openjdk.org/jdk/pull/11188


More information about the hotspot-compiler-dev mailing list