RFR: 8321605: GenShen: Old generation reference process is never reset

[William Kemper]

On Fri, 8 Dec 2023 19:41:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 688:
>> 
>>> 686:     ShenandoahInitMarkUpdateRegionStateClosure cl;
>>> 687:     heap->parallel_heap_region_iterate(&cl);
>>> 688:     heap->old_generation()->ref_processor()->reset_thread_locals();
>> 
>> Why don't we reset the thread locals in the else arm as well?
>> 
>> Is there a less error-prone way of doing this at the time that a new GC cycle that will do discovery is set up?
>> 
>> I realize my questions may be a bit naive as I don't have a full understanding of how the reference processor's state/initialization is handled overall.
>> 
>> For example, we do a bunch of reference processor related stuff further below at line 699. Why not reset the state of thread locals there instead? Would that miss someting?
>> 
>> If I look at the places where this state is reset elsewhere, it seems to occur in the same places where the policy is initialized. If that's done at each cycle that'll do ref-proc, may be that's always the place to reset state/counts?
>
> I see now that this resets the old generation's reference processor. I suspect this is a consequence of the way in which old and young are being handled. A cleaner separation of the two for the generational case might help in the future, and avoid the current more error-prone structure.

I agree, the "bootstrap" cycle for the old generation is poorly modeled.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/367#discussion_r1421012978