RFR: 8376839: GenShen: Improve performance of evacuations into the old generation

Kelvin Nilsen kdnilsen at openjdk.org
Tue Feb 3 18:08:16 UTC 2026


On Mon, 2 Feb 2026 17:26:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 210:
>> 
>>> 208:   log_debug(gc, remset)("Update remembered set from " PTR_FORMAT ", to " PTR_FORMAT, p2i(start), p2i(end));
>>> 209: 
>>> 210:   while (address < end) {
>> 
>> I'm assuming there must be a preparatory pass over all cards to pre-initialize each one, denoting that each card does not hold the start of an object.  Then, this loop changes that state only for the cards that do hold the start of an object.
>> 
>> I haven't worked through the all the details, so my intuition may be wrong here.  But it feels to me like we could skip the preparatory pass by making a small change to how this loop is structured.  The following is my "first" impulse for how I would write this loop.  I'm not sure it's better, but offer it for your consideration.
>> 
>> next_relevant_object = address
>> For each card_index in the range:
>>   if the next_relevant_object pertains to this card {
>>     set_first_start(card_index, offset_in_card(next_relevant_object))
>>     while (next_relevant_object + next_relevant_object->size() < addr_for_card_index(card_index+1)) {
>>       next_relevant_object += next_relevant_object->size();
>>      }
>>      set_last_start(card_index, offset_in_card(next_relevant_object);
>>      next_relevant_object += next_relevant_object->size();
>>   } else {
>>     clear_card_status(card_index);  // no objects start in this card's range
>>   }
>
> Somewhat surprisingly, we clear the card table for old regions when they are initially allocated: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1558.

So that happens when region r is first put into action (having been initially empty).  When we promote regions in place, it looks to me like we (currently) dirty up to top_before_promote, but we don't clean from top to end.  Is this a bug?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29511#discussion_r2760330782


More information about the shenandoah-dev mailing list