RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
Roman Kennke
rkennke at openjdk.org
Mon May 5 15:54:29 UTC 2025
On Mon, 5 May 2025 15:31:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Initialize cardtable_start_address to nullptr
>
> src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42:
>
>> 40: static void pre_barrier(JavaThread* thread, oopDesc* orig) {
>> 41: write_ref_field_pre(orig, thread);
>> 42: }
>
> So, why not export `write_ref_field_pre`, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it in `AOTCache` tables for Leyden benefit.
It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 240:
>
>> 238: cardtable_shift = CardTable::card_shift();
>> 239: } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {
>> 240: cardtable_shift = CardTable::card_shift();
>
> I understand the barrier code does not use `cardtable_start_address`, but should we still initialize it here to `nullptr`?
Good point, did that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073702873
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073705091
More information about the shenandoah-dev
mailing list