RFR: Usage tracking cleanup
William Kemper
wkemper at openjdk.org
Tue Apr 18 23:26:20 UTC 2023
On Tue, 18 Apr 2023 01:55:59 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> There are many nuances to tracing memory utilization. Shenandoah track's usage, waste by humongous objects, padding for promotion LABs alignment and all this is also tracked by generation, the heap and feeds into the heuristics and the pacer. The code to update all of these values and route them to the right places was spread across the allocation call stack. This change consolidates all of the logic into one method, invoked near the end of the allocation.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 779:
>
>> 777: if (ShenandoahPacing) {
>> 778: control_thread()->pacing_notify_alloc(words);
>> 779: pacer()->claim_for_alloc(waste, true);
>
> So, was this a bug in the original code in that we if we generated any waste one would incur a tax on the original allocation twice, rather than only on the waste and cause more stalls than necessary? Or was it the case previously that one was intentionally taxing twice on the allocation for any amount of waste? 🤔
I don't think there was a bug in the original code, I also think this change preserves the original semantics. After this change, the pacer is being informed of the allocation _and_ the waste in the same method call. Previously, `waste` was a boolean and this function would be called twice per allocation - once with `waste` equal to `false` (for the `actual_size`) and again with `waste` equal to `true`. Now, `waste` is just the amount of waste (`size_t`) and this method is called with both `actual_size` and `waste` at the same time.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/260#discussion_r1170659265
More information about the shenandoah-dev
mailing list