RFR: 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation

William Kemper wkemper at openjdk.org
Fri Sep 20 21:36:07 UTC 2024


On Fri, 20 Sep 2024 21:22:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The generational mode for Shenandoah is able to promote regions in place (effectively moving an entire region of live objects, without evacuating any objects). It does this during a normal evacuation phase. However, in some cases, Shenandoah may choose to skip the evacuation phase, _even when there are entire regions to promote_. Prior to this PR, Shenandoah would essentially force itself into an evacuation phase, with nothing to evacuate. Though this was expedient, it cause all manner of knock-on effects and unintended consequences with barriers and asserts and the state of the heap. Here, we have reverted that business and created a path for this special "only doing in place promotions" cycle that does not cause the heap to expect to evacuate objects or find forwarding pointers in them.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 539:
> 
>> 537: 
>> 538:   // Ultimately, the same closure handles in-place promotions for tenured regions. No objects will be moved.
>> 539:   // The threads will still participate in the oom-evac-protocol, although no memory will be allocated for
> 
> Since there is no allocation for promote-in-place promotions, it seems there would be no need for these threads to participate in oom-evac protocol.  (But maybe they still monitor the conditions that would indicate oom-evac just so we can reuse the same code.)

Yes, I was being lazy for the sake of code reuse. This also only happens when it is an abbreviate cycle _and_ there are regions to promote. I'll see what it looks like to not enter the oom-evac-protocol for this case.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/503#discussion_r1769277338


More information about the shenandoah-dev mailing list