RFR: 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits [v2]

[Kelvin Nilsen]

On Thu, 25 Sep 2025 23:56:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Fix up comment
>>  - Merge remote-tracking branch 'jdk/master' into next-bit-may-be-weak
>>  - check for weak bit or strong bit in first bit position
>
> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 138:
> 
>> 136:     idx_t index = to_words_align_down(l_index);
>> 137:     bm_word_t cword = (map(index) ^ flip) >> bit_in_word(l_index);
>> 138:     if ((cword & 0x03) != 0) {
> 
> Can we update the comment below to indicate that we are checking the first two bits because of strong and weak marking? 
> 
> Is there a risk here that dependents of this method will now start treating objects that are only weakly reachable as alive? Or does this fix a bug that caused us to miss such objects?

This does not fix a correctness issue.  This represents a "special" case optimization.

Basically, if either the first weak-mark or first strong-mark bits are set, we want to take this fast path to the return statement.  The code is not wrong if we fail to take this fast path.  It is simply less efficient.

I noticed that the intent of this function is to return the index of the next set bit, regardless of whether it is a weak-mark bit or a strong-mark bit, when I was writing a unit test for this function as part of https://github.com/openjdk/jdk/pull/27353.

In that PR, we introduce a new function complementary function, get_last_bit_impl(), and we use the 0x03 search pattern in that code.  So this fix mirrors the behavior of the new function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27476#discussion_r2381373652