Question about JDK-8192969

[Man Cao]

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/browse/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, and makes it easier
for monitoring tools (e.g. JFR or hsperf counters) to accurately track
promoted bytes.

(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.
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.

-Man

On Sat, Aug 25, 2018 at 2:10 AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi Man,
>
> On Fri, 2018-08-24 at 16:15 -0700, Man Cao wrote:
> > Hi Thomas,
> >
> > (Man from Java platform team at Google here.)
> > I wonder why https://bugs.openjdk.java.net/browse/JDK-8192969 was
> > withdrawn? IHOP should make decisions based only on promoted bytes,
> > but not old-to-old copied bytes in mixed gc, right?
> > We are trying to add an hsperf counter to track promoted bytes in G1,
> > and found this problem with _bytes_allocated_in_old_since_last_gc in
> > G1Policy.
> >
> > I'm happy to look into JDK-8192969 and fix it, but wonder if it was
> > closed because you found other problems with it.
> >
> > If you prefer, JC (CCed) could help me post comments on JBS, or I can
> > start a discussion on hotspot-gc-dev.
>
>   I think this has been fixed in 9 with the adaptive IHOP changes (JDK-
> 8136677).
> See the call to update_ihop_prediction() in g1Policy.cpp which passes
> "_bytes_allocated_in_old_since_last_gc", i.e. only the amount of memory
> added to old.
>
> If you have further questions (and in general I would prefer), please
> use hotspot-gc-dev for gc dev related questions. I am on vacation the
> whole next week and won't be able to answer emails. If I hadn't looked
> at emails just before leaving you would have waited more than a week
> for an answer ;)
>
> Thanks,
>   Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180831/36a39ae7/attachment.htm>