
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi, I hope this is the right list for this question:<div><br></div><div>I was investigating abortable preclean timeouts in our app (and associated long remark pause) so had a look at the old jdk6 code I had on my box, wondered about recording eden chunks during certain eden slow allocation paths (I wasn’t sure if TLAB allocation is just a CAS bump), and saw what looked perfect in the latest code, so was excited to install 1.7.0_60-b19</div><div><br></div><div>I wanted to ask what you consider the stability of these two options to be (I’m pretty sure at least the first one is new in this release)</div><div><br></div><div>I have just installed locally on my mac, and am aware of <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809">http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809</a> which I could reproduce, however I wasn’t able to reproduce it without -XX:-<span style="background-color: rgb(255, 255, 255); white-space: pre-wrap;">UseCMSCompactAtFullCollection (is this your understanding too?)</span></div><div><br></div><div>We are running our application with 8 gig young generation (6.4g eden), on boxes with 32 cores… so parallelism is good for short pauses</div><div><br></div><div>we already have</div><div><br></div><div><div>-XX:+UseParNewGC </div><div>-XX:+UseConcMarkSweepGC</div><div>-XX:+CMSParallelRemarkEnabled</div></div><div><br></div><div>we have seen a few long(isn) initial marks, so </div><div><br></div><div>-XX:+CMSParallelInitialMarkEnabled sounds good</div><div><br></div><div>as for </div><div><br></div><div>-XX:+CMSEdenChunksRecordAlways</div><div><br></div><div>my question is: what constitutes a slow path such an eden chunk is potentially recorded… TLAB allocation, or more horrific things; basically (and I’ll test our app with -XX:+CMSPrintEdenSurvivorChunks) is it likely that I’ll actually get less samples using -XX:+CMSEdenChunksRecordAlways in a highly multithread app than I would with sampling, or put another way… what sort of app allocation patterns if any might avoid the slow path altogether and might leave me with just one chunk?</div><div><br></div><div>Thanks,</div><div><br></div><div>Graham</div><div><br></div><div>P.S. less relevant I think, but our old generation is 16g</div><div>P.P.S. I suspect the abortable preclean timeouts mostly happen after a burst of very high allocation rate followed by an almost complete lull… this is one of the patterns that can happen in our application</div></body></html>