<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks for the answer before vacation, Thomas!<div><br></div><div>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().</div><div>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.</div><div>The code was initially introduce in <a href="https://bugs.openjdk.java.net/browse/JDK-8136681" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8136681</a>.</div><div><br></div><div>My follow-up questions are:</div><div>(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.</div><div><br></div><div>(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.</div><div>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.</div><div>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.<br></div><div>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.<br></div><div><br></div><div><div><div dir="ltr" class="m_4746645277716157378gmail_signature"><div dir="ltr">-Man</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 25, 2018 at 2:10 AM Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Man,<br>
<br>
On Fri, 2018-08-24 at 16:15 -0700, Man Cao wrote:<br>
> Hi Thomas,<br>
> <br>
> (Man from Java platform team at Google here.)<br>
> I wonder why <a href="https://bugs.openjdk.java.net/browse/JDK-8192969" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8192969</a> was<br>
> withdrawn? IHOP should make decisions based only on promoted bytes,<br>
> but not old-to-old copied bytes in mixed gc, right?<br>
> We are trying to add an hsperf counter to track promoted bytes in G1,<br>
> and found this problem with _bytes_allocated_in_old_since_last_gc in<br>
> G1Policy.<br>
> <br>
> I'm happy to look into JDK-8192969 and fix it, but wonder if it was<br>
> closed because you found other problems with it.<br>
> <br>
> If you prefer, JC (CCed) could help me post comments on JBS, or I can<br>
> start a discussion on hotspot-gc-dev.<br>
<br>
  I think this has been fixed in 9 with the adaptive IHOP changes (JDK-<br>
8136677).<br>
See the call to update_ihop_prediction() in g1Policy.cpp which passes<br>
"_bytes_allocated_in_old_since_last_gc", i.e. only the amount of memory<br>
added to old.<br>
<br>
If you have further questions (and in general I would prefer), please<br>
use hotspot-gc-dev for gc dev related questions. I am on vacation the<br>
whole next week and won't be able to answer emails. If I hadn't looked<br>
at emails just before leaving you would have waited more than a week<br>
for an answer ;)<br>
<br>
Thanks,<br>
  Thomas<br>
<br>
</blockquote></div></div></div></div></div></div></div></div>