<p dir="ltr">Ramki, are you running tiered compilation?</p>
<p dir="ltr">sent from my phone</p>
<div class="gmail_quote">On Jul 31, 2015 2:19 PM, "Srinivas Ramakrishna" <<a href="mailto:ysr1729@gmail.com">ysr1729@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div>Hello GC and Compiler teams!<div><br><div>One of our services that runs with several thousand threads recently noticed an increase</div><div>in safepoint stop times, but not gc times, upon transitioning to JDK 8.</div><div><br></div><div>Further investigation revealed that most of the delta was related to the so-called</div><div>pre-gc/vmop "cleanup" phase when various book-keeping activities are performed,</div><div>and more specifically in the portion that walks java thread stacks single-threaded (!)</div><div>and updates the hotness counters for the active nmethods. This code appears to</div><div>be new to JDK 8 (in jdk 7 one would walk the stacks only during code cache sweeps).</div><div><br></div><div>I have two questions:</div><div>(1) has anyone else (typically, I'd expect applications with many hundreds or thousands of threads)</div><div>noticed this regression?</div><div>(2) Can we do better, for example, by:</div><div>      (a) doing these updates by walking thread stacks in multiple worker threads in parallel, or best of all:</div><div>      (b) doing these updates when we walk the thread stacks during GC, and skipping this phase entirely</div><div>            for non-GC safepoints (with attendant loss in frequency of this update in low GC frequency</div><div>            scenarios).</div><div><br></div><div>It seems kind of silly to do GC's with many multiple worker threads, but do these thread stack</div><div>walks single-threaded when it is embarrasingly parallel (one could predicate the parallelization</div><div>based on the measured stack sizes and thread population, if there was concern on the ovrhead of</div><div>activating and deactivating the thread gangs for the work).</div><div><br></div><div>A followup question: Any guesses as to how code cache sweep/eviction quality might be compromised if one</div><div>were to dispense with these hotness updates entirely (or at a much reduced frequency), as a temporary</div><div>workaround to the performance problem?</div><div><br></div><div>Thoughts/Comments? In particular, has this issue been addressed perhaps in newer JVMs?</div><div><br></div><div>Thanks for any comments, feedback, pointers!</div><div>-- ramki</div><div><br></div><div>PS: for comparison, here's data with +TraceSafepointCleanup from JDK 7 (first, where this isn't done)</div><div>vs JDK 8 (where this is done) with a program that has a few thousands of threads:</div><div><br></div><div><br></div><div><br></div><div>JDK 7:</div><div>..</div><div>2827.308: [sweeping nmethods, 0.0000020 secs]</div><div>2828.679: [sweeping nmethods, 0.0000030 secs]</div><div>2829.984: [sweeping nmethods, 0.0000030 secs]</div><div>2830.956: [sweeping nmethods, 0.0000030 secs]</div><div>..</div><div><br></div><div>JDK 8:</div><div>..</div><div>7368.634: [mark nmethods, 0.0177030 secs]</div><div>7369.587: [mark nmethods, 0.0178305 secs]</div><div>7370.479: [mark nmethods, 0.0180260 secs]</div><div>7371.503: [mark nmethods, 0.0186494 secs]</div><div>..</div><div><br></div></div></div>
</blockquote></div>