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