Discussion on JDK-8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC

[Thomas Schatzl]

Hi,

On 27.05.20 18:11, Luo, Ziyi wrote:
> Hi Thomas,
> 
> On 5/27/20, 3:24 AM, Thomas Schatzl wrote:
>      
>> Looking forward to your review request. :) (Fwiw, at this time
>> reviewing, or at least reviewers okay'ing it, must happen in the mailing
>> list as per https://openjdk.java.net/contribute/).
> 
> First, my appreciation for explaining the Adaptive IHOP mechanism and the big
> picture in great details in the other thread, especially the
> additional_buffer_bytes part which I was quite confused when reading the
> source code. I see the need for feeding more allocation info to the Adaptive
> IHOP in order to achieve a more accurate estimation of both the long-term
> allocation rate and short-term allocation spike. In reply to two of your
> comments:
> 
>> In email: the change imho needs to provide some measure of the spikyness of
> the allocation between gcs
>> In JBS: one other improvement could be to put the old gen allocation
> tracking into its own class (e.g. G1OldGenAllocationTracker; which G1Policy
> has an instance of)
> 
> I totally agree on tracking the old gen allocation in a separate class which
> allows us to track and feed more allocation info to the Adaptive IHOP. That's
> the reason I haven't publish an RFR for JDK-8245511. The question I raised in
> the other email thread
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-May/029824.html
> shows that not all humongous allocations are properly tracked, which I believe
> can be addressed at the same time while refactoring the old gen tracking into
> a separate class. 

Okay. :)

> Without fixing the humongous tracking, my first webrev
> revision is premature for a review. I also agree not to overload Adaptive IHOP
> for tracking the humongous allocation history. Here's my current plan toward
> fixing JDK-8245511:
> 
> * I'll create a separate bug ID for refactoring the G1 old gen allocation
> tracking and providing better humongous allocation tracking and submit an RFR
> for that.
> * I'll then refactor my current patch and address comments in the JBS for
> JDK-8245511 based on the refactored old gen allocation tracker.
> 
> Does the plan make sense to you?
> 

Fine with me. Still looking forward to the review :)

Thanks,
   Thomas