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

[Kelvin Nilsen]

On Fri, 26 Sep 2025 08:32:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.

I'll fix this comment.

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

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