RFR: JDK-8262068: Improve G1 Full GC by skipping compaction for regions with high survival ratio [v14]

Thomas Schatzl tschatzl at openjdk.java.net
Fri Apr 9 10:53:20 UTC 2021


On Thu, 8 Apr 2021 13:44:35 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Some more investigation and discussion about the BOT handling showed that we need to update the BOT for these Survivor-turned-to-Old regions after all.
>> 
>> The reason is that contrary to what I thought, while BOT can handle queries for object start addresses above the "last known valid entry" (materialized in `_next_offset_threshold` and `_next_offset_index` ) mentioned in PR#3356, it only does so slowly, and while updating the BOT itself, not updating that "last known valid entry".
>> So every time it queries for an object start in such regions, it starts walking from the bottom of that region.
>> 
>> See the call chain `G1BlockOffsetTablePart::block_start` -> `forward_to_block_containing_addr` -> `forward_to_block_containing_addr_slow` where the call to `alloc_block_work` in `g1BlockOffsetTable.cpp:236` only updates local boundary and index (not `_next_offset_threshold` and `_next_offset_index`).
>> 
>> This is a problem for young gcs as this behavior will make them slower than expected. Since it is impossible to make the updates to both `_next_offset_threshold` and `_next_offset_index` atomic, and another issue anyway; feel free to file an issue) I would prefer to penalize full gc (that is, keep old behavior) for that.
>> 
>> The alternative would be to just `alloc_block` the whole region (so that `next_offset_index` and friend are at the top), but I think given the rarity of this case and full gc in general it is better to do the extra work in the full gc.
>> 
>> Could you add code that walks such full young regions and does the `cross_threshold` thing? This additional code certainly does not need to actually compact these regions.
>> 
>> Thanks,
>>   Thomas
>
> Thanks for discussion! I had the same concern (BOTs of these Survivor-turned-to-Old regions contains no useful info, so might make it very slow when finding block start in these regions), but I was not sure if there is some "lazy" mechanism to fill valid BOTs info for these regions when they are accessed subsequently. I just not have time to do further investigation, now I got the answer from you. 
> 
> Sure I will add code to fill valid BOTs info for these young regions by the end of full gc.
> I'm not sure if it's OK for me to do this BOTs filling action in a separate issue? As we already had such a long discussion, I think it's might be better for us to initialize another discussion for this specific follow-up issue. Please kindly let me know your thoughts.

It is fine with me to fix this separately.

There is some lazy mechanism to fill this BOT, but it does not work in this case (which is the gist of what I said above).

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

PR: https://git.openjdk.java.net/jdk/pull/2760



More information about the hotspot-gc-dev mailing list