RFR: Loan from old should align on region size
Y. Srinivas Ramakrishna
ysr at openjdk.org
Wed Feb 1 07:52:30 UTC 2023
On Wed, 1 Feb 2023 03:42:08 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 732:
>>
>>> 730: working_old_available -= additional_regions_to_loan * region_size_bytes;
>>> 731: }
>>> 732: size_t allocation_supplement = old_bytes_reserved_for_alloc_supplement + old_bytes_loaned_for_young_evac;
>>
>> So, each of these may not themselves be an integral multiple of region size but their sum is (by the assert on the next line).
>>
>> Can we reason through why this should follow? It must be that at some point we end up using a fraction of sum of region sizes and then they come together here. Could you help document that, or point to the relevant split that then merges them back here? I'll try and look through the flow as well, although the calculations are quite complex to keep track of unless one knows the rationale well to see where the fractional regions come about and where the complementary fraction is then held.
>
> If you follow the computations, you'll see there's a "remnant" of memory that is leftover after we set aside certain regions to support young evacuations. That "remnant" is added into the allocation supplement. The remnant is what causes each of the individual values to possibly be unaligned.
Thanks, yes, that makes sense. So may be leave a comment such as:
// `available_loan_remnant' may contain a fractional region that was removed from the
// whole number of regions that were loaned for young evacuation (the second addend below).
// That loan remnant was added to the old bytes reserved for the allocation supplement (the first addend below).
// As a result, their sum is back to being a whole number of regions; we only want to transfer
// whole regions between the two generations.
Or something to that effect. May be it's clear to the reader sufficiently versed with the logic of the accounting
represented here, in which case feel free to ignore the suggestion of a comment.
-------------
PR: https://git.openjdk.org/shenandoah/pull/213
More information about the shenandoah-dev
mailing list