<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Aleksey,</div><div><br></div><div>The patch looks mostly good to me but I think I found a minor behavior change (bug).</div>It seems it causes double counting on CollectedHeap._total_full_collections, if complete==true && do_young_collection==true && <span style="color:rgb(0,0,0)">do_full_collection==true.</span></div><div dir="ltr"><font color="#000000">The cause is the following: <br></font><div><pre style="color:rgb(0,0,0)"> 645     if (!do_young_collection) {
 646       gc_prologue(complete);
 647       increment_total_collections();
 648     }
 649     increment_total_full_collections();</pre>I can expose the issue with the following command:<br>$ java -XX:+UseSerialGC -XX:+ScavengeBeforeFullGC -Xlog:gc*,gc+heap=debug -Xmx30m -jar dacapo-9.12-bach.jar fop -n 5<br>Then compare the number of lines with "Pause Full" against the full count in the line "Heap after GC invocations=XX (full XX)" after last GC.<br><br>I found the following could fix the problem (yes, it's ugly, but I couldn't find cleaner way that works in all cases):</div><div><br></div><div>if (!do_young_collection) {<br></div><div>  gc_prologue(complete);<br>  increment_total_collections(complete);<br>}<br>if (!complete) {<br>  increment_total_full_collections();<br>}</div><div><br></div>I also found that CollectedHeap._total_collections seems wrong with or without this change, for SerialGC and CMS.</div><div dir="ltr">It is smaller than the actual number of collections according to the GC ID. Reproduction recipe is the same as above.<div><br></div><div>-Man<br></div></div></div></div></div></div></div>