RFR: 8333750: GenShen: Only instantiate young/old generations in generational mode [v3]
William Kemper
wkemper at openjdk.org
Tue Jun 11 18:06:38 UTC 2024
On Tue, 11 Jun 2024 01:06:42 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> William Kemper has updated the pull request incrementally with three additional commits since the last revision:
>>
>> - Make age and youth const
>> - Do not age regions after completing old mark
>> - Detect cancellation of old GC after final mark.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 734:
>
>> 732: } else {
>> 733: _heap->generation_for(r->affiliation())->increment_affiliated_region_count();
>> 734: }
>
> Can the affiliation update be done unconditionally outside of the if-else, as when the affiliation is set at line 721, or if it needs to be done after the old region coalesce/fill/card-clearing, then after that at line 733, but unconditionally, skipping the update at line 731 for the old gen?
Yes, that should be fine.
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2044:
>
>> 2042: }
>> 2043:
>> 2044: global_generation()->cancel_marking();
>
> Not that this matters, but there are a few methods `foo()` on the heap that do an operation on global and, in generational mode, on old and young. If possible, I'd use the same idiom in them uniformly(unless there is a good reason not to), i.e.
> `ShenandoahHeap::foo() {
> global_gen->foo();
> if (generational) {
> young->foo();
> old->foo();
> }
> `
>
> In fact, you could just do this by means of a macro like `ALL_GENS(x)` which does this for you?
>
> e.g. `set_mark_complete`, `set_mark_incomplete`, etc. (Not sure if there are several others in the same fashion, and therefore if it's worthwhile to macro-ize or not.
I'll consider this for another PR. I think there are only a couple of places that would fit such a macro precisely and I'm not sure the obfuscating effects would be worth it.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/444#discussion_r1635284848
PR Review Comment: https://git.openjdk.org/shenandoah/pull/444#discussion_r1635291010
More information about the shenandoah-dev
mailing list