[G1] Why humongous object bytes allocated after a collection are not recorded in G1Policy::_bytes_allocated_in_old_since_last_gc?
luoziyi at amazon.com
Mon May 25 16:16:19 UTC 2020
>On 23.05.20 00:30, Luo, Ziyi wrote:
>> I have a question about humongous object allocation result in g1CollectedHeap:
>> L874 returns the result after a successful humongous allocation. L893 returns
>> the result after a successful G1CollectForAllocation. In the former case, the
>> allocated bytes are recorded in
>> G1Policy::_bytes_allocated_in_old_since_last_gc in L873. But bytes in the
>> latter case are not. Is this intentional or a mistake?
> the collection itself has some code to add the allocated bytes. In
>the first case since there is no collection, that value needs to be
>But you probably already know that, you filed JDK-8245511 :)
Yes, this is about JDK-8245511. In IHOP, _bytes_allocated_in_old_since_last_gc
is used to calculate the old gen allocation rate. In some jtreg tests (e.g., gc
/TestSoftReferencesBehaviorOnOOME), I observed the following gc log output:
GC(215) Pause Full (G1 Humongous Allocation)
GC(215) Humongous regions: 0->0
GC(216) Basic information (value update) ... recent allocation size: 0B,
recent allocation duration: 173.09ms, recent old gen allocation rate: 0.00B/s
GC(216) Humongous regions: 111->111
Correct me if I were wrong: The allocated bytes during G1CollectForAllocation
are considered as "on gc allocation". Since they are allocated during a pause,
they should not be used to calculate the old gen allocation rate, thus are not
included in G1Policy::_bytes_allocated_in_old_since_last_gc.
If that's the case, for JDK-8245511, I need to adjust how the survived
humongous regions in a GC is recorded.
More information about the hotspot-gc-dev