<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 06/12/2014 09:16 PM, graham
sanderson wrote:<br>
</div>
<blockquote cite="mid:43FD20E2-774A-4F30-ACEA-F10395175C82@vast.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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
moz-do-not-send="true"
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>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:43FD20E2-774A-4F30-ACEA-F10395175C82@vast.com"
type="cite">
<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>
</blockquote>
<br>
Fast path allocation is done from TLAB's. If you have to get<br>
a new TLAB, the call to get the new TLAB comes from compiled<br>
code but the call is into the JVM and that is the slow path where<br>
the sampling is done.<br>
<br>
Jon<br>
<br>
<blockquote cite="mid:43FD20E2-774A-4F30-ACEA-F10395175C82@vast.com"
type="cite">
<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>
</blockquote>
<br>
</body>
</html>