RFR: Loan from old should align on region size
Kelvin Nilsen
kdnilsen at openjdk.org
Wed Feb 1 03:44:24 UTC 2023
On Wed, 1 Feb 2023 03:10:09 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> This fixes an error detected by a recently added assertion on a different branch. When loaning memory from old-gen to young-gen, it is important the total amount of the loan be an integral number of ShenandoahHeapRegions. The total loan represents a sum of memory loaned to support young evacuations and memory loaned to support mutator allocations made while GC is active. The sum of these two values is a multiple of region size. The previous version of the code accidentally loaned only the memory dedicated to supporting mutator allocations, which is not necessarily a multiple of the region size.
>
> 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.
-------------
PR: https://git.openjdk.org/shenandoah/pull/213
More information about the shenandoah-dev
mailing list