RFR: 8339611: GenShen: Simplify ShenandoahOldHeuristics::trigger_collection_if_fragmented [v3]

Y. Srinivas Ramakrishna ysr at openjdk.org
Wed Sep 11 00:02:30 UTC 2024


On Mon, 9 Sep 2024 20:43:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Replace iterative solution with a single mathematical computation, and adjust old-gen defragmentation efforts to be a bit less aggressive.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments and clarify intent of old_region_span

Left a few clean up comments to make it more readable and more easily understandable.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 552:

> 550: // is required to represent the memory currently used within the old generation.  This trigger looks specifically
> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.

I realize this is a private API / work method. Would still be good to place the documentation comment in the .hpp file.


// If the old generation is fragmented, set appropriate collection triggering signals.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 553:

> 551: // at density of the old-gen spanned region.  A different mechanism triggers old-gen GC if the total number of
> 552: // old-gen regions (regardless of how close the regions are to one another) grows beyond an anticipated growth target.
> 553: void ShenandoahOldHeuristics::trigger_collection_if_fragmented(size_t first_old_region, size_t last_old_region,

I'd name this method `set_fragmentation_trigger()`, with the side-effect that the fragmentation measures are recorded for logging, and associated triggers are set which are used later to start an old cycle.

I'd then rename `trigger_maybe()` to `set_triggers()`, and rename `trigger_collection_if_overgrown()` to `set_growth_trigger()`, etc.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 558:

> 556:     // Our intent is to pack old-gen memory into the highest-numbered regions of the heap.  Count all memory
> 557:     // above first_old_region as the "span" of old generation.
> 558:     size_t old_region_span = (first_old_region <= last_old_region)? (num_regions - first_old_region): 0;

Can it ever be the case that `first_old_region > last_old_region` ? When can that be the case?

Then, `old_region_span = 0`....

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 573:

> 571:     size_t old_words_consumed = old_region_count * region_size_words - old_fragmented_available;
> 572:     size_t old_words_spanned = old_region_span * region_size_words;
> 573:     double old_density = ((double) old_words_consumed) / old_words_spanned;

... and if `old_region_span = 0`, then you end up with line 573 causing a divide-by-zero error.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 590:

> 588:       //  old_span_percent is  60% and old_density is below 27.0%, or
> 589:       //  old_span_percent is  50% and old_density is below 18.8%.
> 590:       trigger_old_is_fragmented(old_density, first_old_region, last_old_region);

This method seems a bit useless, why not inline the assignment here? I realize you may be trying to make this method span fewer lines, but I think that can be easily achieved by just moving the description of its work out of line from the code into a block comment at the start that describes how fragmentation is computed and what the trigger threshold criteria are.

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

PR Review: https://git.openjdk.org/shenandoah/pull/492#pullrequestreview-2294311123
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752935743
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752941163
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752945550
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752946402
PR Review Comment: https://git.openjdk.org/shenandoah/pull/492#discussion_r1752947994


More information about the shenandoah-dev mailing list