RFR: 8325673: GenShen: Share Reserves between Old and Young Collector [v6]

Y. Srinivas Ramakrishna ysr at openjdk.org
Thu Jul 25 01:07:59 UTC 2024


On Wed, 24 Jul 2024 15:11:56 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 156:
> 
>> 154:   bool top_off_collection_set();
>> 155: 
>> 156:   // Return true iff the collection set holds at least one unpinned mixed evacuation candidate
> 
> Same comment as the last one. The comment must not only state the value returned, but also what actions the method takes or side-effect it has on this or another interacting object's state. You want to do that for all imperative methods. (Only accessor methods may have a single line stating what they return; otherwise the effect of the method should be described.)

(Applies to all the methods line 150-157.)

> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 226:
> 
>> 224:     // on its next iteration and run a degenerated young cycle.
>> 225: 
>> 226:     // vmop_entry_final_updaterefs rebuilds free set in preparation for next GC.
> 
> Did you mean to say `vmop_entry_final_roots` in this comment?

Also, are the comments at line 215 and 226 really needed, since the methods do much more than just rebuilding the free set.

> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 342:
> 
>> 340:   op_final_roots();
>> 341: 
>> 342:   if (heap->mode()->is_generational()) {
> 
> Can this code be factored out into a virtual method `rebuild_free_set()` that `ShenandoahGenerationalHeap` overrides?

Also, can you take a look at `op_final_updaterefs` where `rebuild_free_set` is called? There may be an opportunity to refactor the code here into a method as suggested above, and to share that with `rebuild_free_set` perhaps.

> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 752:
> 
>> 750:     //  been set aside to hold objects evacuated from the young-gen collection set.  Conservatively, this value
>> 751:     //  equals the entire amount of live young-gen memory within the collection set, even though some of this memory
>> 752:     //  will likely be promoted.
> 
> It sounds like these comments should be moved (and split) into the `prepare_regions_and_collection_set()` header specification, and in its override for `ShenandoahOldGeneration`?

The TODO comment at lines 727-734 should similarly move out into the method about which it talks.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/395#discussion_r1690632111
PR Review Comment: https://git.openjdk.org/shenandoah/pull/395#discussion_r1690610219
PR Review Comment: https://git.openjdk.org/shenandoah/pull/395#discussion_r1690616973
PR Review Comment: https://git.openjdk.org/shenandoah/pull/395#discussion_r1690620818


More information about the shenandoah-dev mailing list