Question about JDK-8192969

[Thomas Schatzl]

Hi,

On Fri, 2018-08-31 at 15:43 -0700, Man Cao wrote:
> Thanks for the answer before vacation, Thomas!
> 
> I checked and it is indeed not tracking old-to-old copied bytes in
> mixed GC. The reason is that in G1Policy::update_ihop_prediction(),
> the call to _ihop_control->update_allocation_info() is guarded by
> "this_gc_was_young_only", which is collector_state()-
> >in_young_only_phase().
> So adaptive IHOP is only considering
> _bytes_allocated_in_old_since_last_gc for young-only collections.
> This would only include promoted bytes and humongous allocations.
> The code was initially introduce in https://bugs.openjdk.java.net/bro
> wse/JDK-8136681.
> 
> My follow-up questions are:
> (a) Should adaptive IHOP take the promoted bytes during mixed
> collections into account? Currently it seems omitting these bytes
> altogether. Looking at the code, it is not that straightforward to
> separate young-to-old promoted bytes and old-to-old copied bytes
> during a mixed collection, because they use the same PLAB mechanism.
> Nevertheless, the benefit is that it would make adaptive IHOP's
> statistics more accurate,

When implementing adaptive IHOP there have iirc been two reasons to not
 add information during mixed gc to the estimation:

- it would take some effort to extract young-to-old promoted bytes from
old-to-old promoted bytes which would require some care regarding
performance impact.

- the young-to-old promotion rate during mixed gc may be significantly
different due to the much more frequent GCs because of the smaller
young gen (ie. objects have typically significantly "less time to die"
during mixed gc).

Not sure if that helps the estimation.

Another point is that during mixed gc you typically want that the
amount of heap occupancy decreases (i.e. young-to-old promotion < freed
space). Any mixed gc that does not free more space in old gen than it
adds to old gen (due to young-to-old promotion) is kind of wasted
effort.

This means given this assumption holds, you can't go out of memory due
to inexact estimation during the mixed phase.

If this assumption does not hold, G1 would need to decide if it should
continue with that mixed phase or not (or keep intensifying its efforts
to clean up old gen, potentially blowing the pause time goal), which is
 unfortunately not trivial.

I think this has been the main motivation to not do that at that time.
It may be interesting to revisit that.

>  and makes it easier for monitoring tools (e.g. JFR or hsperf
> counters) to accurately track promoted bytes.

That is indeed true - there is actually an RFE to fix this JDK-8073051.

> (b) For humongous allocations, I think it may be better to track them
> separately and develop better heuristics for initiating concurrent
> mark at humongous allocations.
> The reason is that we have tried G1 on several production teams, and
> 2 teams have seen many humongous allocations that triggers back-to-
> back concurrent marks without reclaiming much memory, resulting in a
> situation similarly to GC thrashing and wasting precious CPU time.
> The region sizes were 2MB and 4MB.

JDK-8163579 may be one instance of what you are experiencing: due to
humongous objects G1 frequently crosses the IHOP threshold, causing an
initial mark, but due to eager reclaim it never actually increases the
IHOP because it never starts mixed gcs as there are no (or almost none)
regular objects to reclaim.

I think I still have a crude prototype change that implements what is
suggested there to share.

> I'm able to reproduce the back-to-back concurrent marks issue by
> modifying BigRamTester to allocate humongous objects. I'll probably
> ask JC to help me create an RFE for this thrashing issue.
> In general, humongous objects are probably not that rare in our
> workload, and there is still room for improvement in how G1 handles
> humongous objects.

There are a few open CRs for them, feel free to pick up some :)

You might want to look through all CRs with the "gc-g1" label and the
term "humongous" in the bug tracker. Depending on your problem, and
what you are interested to fix in this area, browsing through them
might give you some ideas.

Keep us updated with your efforts.

Thanks,
  Thomas