
<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Thomas,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Inline.</div> <br><p class="airmail_on">On January 12, 2016 at 7:00:45 AM, Thomas Schatzl (<a href="mailto:thomas.schatzl@oracle.com">thomas.schatzl@oracle.com</a>) wrote:</p> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div></div><div>Hi,<span class="Apple-converted-space"> </span><br><br>On Mon, 2016-01-11 at 12:59 -0500, Tony Printezis wrote:<span class="Apple-converted-space"> </span><br>> Hi all,<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> We have been recently investigating some very lengthy (several<span class="Apple-converted-space"> </span><br>> minutes) promotion failures in ParNew, which also appear in<span class="Apple-converted-space"> </span><br>> ParallelGC. We have identified a few issues and have some fixes to<span class="Apple-converted-space"> </span><br>> address them. Here's a quick summary:<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> 1) There's a scalability bottleneck when adding marks to the<span class="Apple-converted-space"> </span><br>> preserved mark stack as there is only one stack, shared by all<span class="Apple-converted-space"> </span><br>> workers, and pushes to it are protected by a mutex. This essentially<span class="Apple-converted-space"> </span><br>> serializes all workers if there is a non-trivial amount of marks to<span class="Apple-converted-space"> </span><br>> be preserved. The fix is similar to what's been implemented in G1 in<span class="Apple-converted-space"> </span><br>> JDK 9, which is to introduce per-worker preserved mark stacks.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> 2) (More interestingly) I was perplexed by the huge number of marks<span class="Apple-converted-space"> </span><br>> that I see getting preserved during promotion failure. I did a small<span class="Apple-converted-space"> </span><br>> study with a test I can reproduce the issue with. The majority of the<span class="Apple-converted-space"> </span><br>> preserved marks were 0x5 (i.e. "anonymously biased"). According to<span class="Apple-converted-space"> </span><br>> the current logic, no mark is preserved if it's biased, presumably<span class="Apple-converted-space"> </span><br>> because it's assumed that the object is biased towards a specific<span class="Apple-converted-space"> </span><br>> thread and we want to preserve that mark as it contains the thread<span class="Apple-converted-space"> </span><br>> pointer.<span class="Apple-converted-space"> </span><br><br>I think the reason is that nobody ever really measured the impact of<span class="Apple-converted-space"> </span><br>biased locking on promotion failures, and so never considered it.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>I bet. :-)</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>> The fix is to use a different default mark value when biased locking<span class="Apple-converted-space"> </span><br>> is enabled (0x5) or disabled (0x1, as it is now). During promotion<span class="Apple-converted-space"> </span><br><br>> failures, marks are not preserved if they are equal to the default<span class="Apple-converted-space"> </span><br>> value and the mark of forwarded objects is set to the default value<span class="Apple-converted-space"> </span><br>> post promotion failure and before the preserved marks are re<span class="Apple-converted-space"> </span><br>> -instated.<span class="Apple-converted-space"> </span><br><br>You mean the value of the mark as it is set during promotion failure<span class="Apple-converted-space"> </span><br>for the new objects?<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Not sure what you mean by “for new objects”.</p><p>Current state: When we encounter promotion failures, we check whether the mark is the default (0x1). If it is, we don’t preserve it. If it is not, we preserve it. After promotion failure, we iterate over the young gen and set the mark of all objects (ParNew) or all forwarded objects (ParallelGC) to the default (0x1), then apply all preserved marks.</p><p>What I’m proposing is that in the process I just described, the default mark will be 0x5, if biased locking is enabled (as most objects will be expected to have a 0x5 mark) and 0x1, if biased locking is disabled (as it is the case right now).</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>Did some very quick measurements on the distribution of marks on a few<span class="Apple-converted-space"> </span><br>certainly also non-representative workloads and can see your point.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>I also did that for synthetic tests and I see the same. I’ll try to get some data from production.</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>When running without biased locking, the amount of preserved marks is even lower.</div></div></span></blockquote></div><p><br></p><p>Of course, because the the most populous mark will be 0x1 when biased locking is disabled, not 0x5. The logic of whether to preserve a mark or not was taken before biased locking was introduced, when most objects would have a 0x1 mark. Biased locking changed this behavior and most objects have a 0x5 mark, which invalidated the original assumptions.</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><span class="Apple-converted-space"> </span>That may be an option in some cases in addition to these suggested changes.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Not sure what you mean.</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>> A few extra observations on this:<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> - I don't know if the majority of objects we'll come across during<span class="Apple-converted-space"> </span><br>> promotion failures will be anonymously biased (it is the case for<span class="Apple-converted-space"> </span><br>> synthetic benchmarks). So, the above might pay off in certain cases<span class="Apple-converted-space"> </span><br>> but not all. But I think it's still worth doing.<span class="Apple-converted-space"> </span><br><br>I tend to agree since after looking through the biased locking code a<span class="Apple-converted-space"> </span><br>bit, it seems that by default new objects are anonymously biased with<span class="Apple-converted-space"> </span><br>biased locking on, so this will most likely help decreasing the amount<span class="Apple-converted-space"> </span><br>of marks to preserved.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Yes, I agree with this.</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>> - Even though the per-worker preserved mark stacks eliminate the big<span class="Apple-converted-space"> </span><br>> scalability bottleneck, reducing (potentially dramatically) the<span class="Apple-converted-space"> </span><br>> number of marks that are preserved helps in a couple of ways: a)<span class="Apple-converted-space"> </span><br>> avoids allocating a lot of memory for the preserved mark stacks<span class="Apple-converted-space"> </span><br>> (which can get very, very large in some cases) and b) avoids having<span class="Apple-converted-space"> </span><br>> to scan / reclaim the preserved mark stacks post promotion failure,<span class="Apple-converted-space"> </span><br>> which reduces the overall GC time further. Even the parallel time in<span class="Apple-converted-space"> </span><br>> ParNew improves by a bit because there are a lot fewer stack pushes<span class="Apple-converted-space"> </span><br>> and malloc calls.<span class="Apple-converted-space"> </span><br><br>... during promotion failure.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Yes, I’m sorry I was not clear. ParNew times improve a bit when they encounter promotion failures.</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>> 3) In the case where lots of marks need to be preserved, we found<span class="Apple-converted-space"> </span><br>> that using 64K stack segments, instead of 4K segments, speeds up the<span class="Apple-converted-space"> </span><br>> preserved mark stack reclamation by a non-trivial amount (it's 3x/4x<span class="Apple-converted-space"> </span><br>> faster).<span class="Apple-converted-space"> </span><br><br>In my tests some time ago, increasing stack segment size only helped a<span class="Apple-converted-space"> </span><br>little, not 3x/4x times though as reported after implementing the per<span class="Apple-converted-space"> </span><br>-thread preserved stacks.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>To be clear: it’s only the reclamation of the preserved mark stacks I’ve seen improve by 3x/4x. Given all the extra work we have to do (remove forwarding references, apply preserved marks, etc.) this is a very small part of the GC when a promotion failure happens. But, still...</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>A larger segment size may be a better trade-off for current, larger app<span class="Apple-converted-space"> </span><br>lications though.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Is there any way to auto-tune the segment size? So, the larger the stack grows, the larger the segment size?</p><p><br></p><div><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>> We have fixes for all three issues above for ParNew. We're also going<span class="Apple-converted-space"> </span><br>> to implement them for ParallelGC. For JDK 9, 1) is already<span class="Apple-converted-space"> </span><br>> implemented, but 2) or 3) might also be worth doing.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Is there interest in these changes?<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>OK, as I said to Jon, I’ll have the ParNew changes ported to JDK 9 soon. Should I create a new CR per GC (ParNew and ParallelGC) for the per-worker preserved mark stacks and we’ll take it from there?</p><p>Tony</p><p><br></p><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><br>Yes.<span class="Apple-converted-space"> </span><br><br>Thanks,<span class="Apple-converted-space"> </span><br>Thomas<span class="Apple-converted-space"> </span><br><br></div></div></span></blockquote><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"></div> <div id="bloop_sign_1452621395324108032" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px"><div>-----</div><div><br></div><div>Tony Printezis | JVM/GC Engineer / VM Team | Twitter</div><div><br></div><div>@TonyPrintezis</div><div><a href="mailto:tprintezis@twitter.com">tprintezis@twitter.com</a></div><div><br></div></div></div></body></html>