
<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 13, 2016 at 11:47:40 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>On Wed, 2016-01-13 at 11:11 -0500, Tony Printezis wrote:<span class="Apple-converted-space"> </span><br>> Thomas,<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Thanks for the reply. Inline.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> On January 13, 2016 at 5:08:04 AM, Thomas Schatzl (<span class="Apple-converted-space"> </span><br>> thomas.schatzl@oracle.com) wrote:<span class="Apple-converted-space"> </span><br>> > Hi,<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > On Tue, 2016-01-12 at 13:15 -0500, Tony Printezis wrote:<span class="Apple-converted-space"> </span><br>> > > Thomas,<span class="Apple-converted-space"> </span><br>> > ><span class="Apple-converted-space"> </span><br>> > > Inline.<span class="Apple-converted-space"> </span><br>> > ><span class="Apple-converted-space"> </span><br>> > > On January 12, 2016 at 7:00:45 AM, Thomas Schatzl (<span class="Apple-converted-space"> </span><br>> > > thomas.schatzl@oracle.com) wrote:<span class="Apple-converted-space"> </span><br>> > > ><span class="Apple-converted-space"> </span><br>> > [...]<span class="Apple-converted-space"> </span><br>> > > ><span class="Apple-converted-space"> </span><br>> > > > > The fix is to use a different default mark value when biased<span class="Apple-converted-space"> </span><br>> > > > > locking is enabled (0x5) or disabled (0x1, as it is now).<span class="Apple-converted-space"> </span><br>> > During<span class="Apple-converted-space"> </span><br>> > > > > promotion failures, marks are not preserved if they are equal<span class="Apple-converted-space"> </span><br>> > to<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > > > > the default value and the mark of forwarded objects is set to<span class="Apple-converted-space"> </span><br>> > the<span class="Apple-converted-space"> </span><br>> > > > > default value post promotion failure and before the preserved<span class="Apple-converted-space"> </span><br>> > > > > marks are re-instated.<span class="Apple-converted-space"> </span><br>> > > ><span class="Apple-converted-space"> </span><br>> > > > You mean the value of the mark as it is set during promotion<span class="Apple-converted-space"> </span><br>> > > > failure for the new objects?<span class="Apple-converted-space"> </span><br>> > > Not sure what you mean by “for new objects”.<span class="Apple-converted-space"> </span><br>> > > Current state: When we encounter promotion failures, we check<span class="Apple-converted-space"> </span><br>> > whether<span class="Apple-converted-space"> </span><br>> > > the mark is the default (0x1). If it is, we don’t preserve it. If<span class="Apple-converted-space"> </span><br>> > it<span class="Apple-converted-space"> </span><br>> > > is not, we preserve it. After promotion failure, we iterate over<span class="Apple-converted-space"> </span><br>> > the<span class="Apple-converted-space"> </span><br>> > > young gen and set the mark of all objects (ParNew) or all<span class="Apple-converted-space"> </span><br>> > forwarded<span class="Apple-converted-space"> </span><br>> > > objects (ParallelGC) to the default (0x1), then apply all<span class="Apple-converted-space"> </span><br>> > preserved<span class="Apple-converted-space"> </span><br>> > > marks.<span class="Apple-converted-space"> </span><br>> > > What I’m proposing is that in the process I just described, the<span class="Apple-converted-space"> </span><br>> > > default mark will be 0x5, if biased locking is enabled (as most<span class="Apple-converted-space"> </span><br>> > > objects will be expected to have a 0x5 mark) and 0x1, if biased<span class="Apple-converted-space"> </span><br>> > > locking is disabled (as it is the case right now).<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > As you mentioned, the default value for new objects is typically<span class="Apple-converted-space"> </span><br>> > not<span class="Apple-converted-space"> </span><br>> > 0x1 when biased locking is enabled, but klass()<span class="Apple-converted-space"> </span><br>> > ->prototype_header().<span class="Apple-converted-space"> </span><br>> (OK, I now understand what you meant by “new objects”.) Indeed. But<span class="Apple-converted-space"> </span><br>> that’s not only the case for new objects. I’d guess that most objects<span class="Apple-converted-space"> </span><br>> will retain their initial mark? Maybe?<span class="Apple-converted-space"> </span><br><br>Hopefully they will :)<span class="Apple-converted-space"> </span><br><br>> > One other "problem" seems to be that some evacuation failure<span class="Apple-converted-space"> </span><br>> > recovery<span class="Apple-converted-space"> </span><br>> > code unconditionally sets the header of the objects that failed<span class="Apple-converted-space"> </span><br>> > promotion but are not in the preserved headers list to 0x1....<span class="Apple-converted-space"> </span><br>> It’d be hard to do otherwise? You’d have to do a look-up on a table<span class="Apple-converted-space"> </span><br>> to see whether the object’s mark should be set to the default or a<span class="Apple-converted-space"> </span><br>> stored value. I think, assuming that most objects have a default mark<span class="Apple-converted-space"> </span><br>> word, setting the mark word of all (forwarded?) objects in the young<span class="Apple-converted-space"> </span><br>> gen to the default, then apply the (hopefully, small number of)<span class="Apple-converted-space"> </span><br>> preserved marks afterwards is not unreasonable.<span class="Apple-converted-space"> </span><br><br>The description in markoop.hpp indicates that a value of 0x1 means for<span class="Apple-converted-space"> </span><br>when biased locking is enabled that that object can not be biased any<span class="Apple-converted-space"> </span><br>more in the future. Hurting future performance after evacuation<span class="Apple-converted-space"> </span><br>failure. So it might not be ideal to unconditionally store 0x1 there.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>I never actually suggested to set the mark word to 1 unconditionally. :-)</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 may be talking in circles here about the same thing, but one other<span class="Apple-converted-space"> </span><br>thought... one may (here I am not completely sure because the existing<span class="Apple-converted-space"> </span><br>code to determine that is somewhat complicated :)) only need to<span class="Apple-converted-space"> </span><br>preserve marks if they are different from the default value (the<span class="Apple-converted-space"> </span><br>condition in markOopDesc::must_be_preserved() may ultimately just boil<span class="Apple-converted-space"> </span><br>down to this). This obviously needs the gc to compare with the existing<span class="Apple-converted-space"> </span><br>klass()->prototype_header().<span class="Apple-converted-space"> </span><br><br>The assumption of your changes that either 0x5 or 0x1 is most common is<span class="Apple-converted-space"> </span><br>just a short-cut to that, but by only putting values into the preserved<span class="Apple-converted-space"> </span><br>mark lists that are non-default (regardless of whether biased locking<span class="Apple-converted-space"> </span><br>is enabled or not), you may get an even lower amount of entries in that<span class="Apple-converted-space"> </span><br>list.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Sure, something to consider. I’d love to get some extensive testing on that change though. :-) (hint, hint)</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>Now the question to me would be, what is more expensive, just assuming<span class="Apple-converted-space"> </span><br>a particular default value at the start (e.g. 0x5 with BiasedLocking<span class="Apple-converted-space"> </span><br>enabled, 0x1 if disabled) is faster, or checking whether the current<span class="Apple-converted-space"> </span><br>value is default or not (or the existing<span class="Apple-converted-space"> </span><br>markOopDesc::must_be_preserved()) and profiting from the reduced amount<span class="Apple-converted-space"> </span><br>of entries later.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Comparing against a constant (or a local field) will most definitely be cheaper (not dereferencing). But, I don’t think that check will have a huge overhead whichever way it’s done. Reducing the number of preserved marks will be more important than optimizing said check. BTW, the check right now is actually quite expensive (checks the UseBiasedLocking flag, etc.). So, we can probably do better whichever way we implement it.</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>> FWIW, it’d be nice if we could completely avoid self-forwarding (and<span class="Apple-converted-space"> </span><br>> a lot of those problems will just go away…).<span class="Apple-converted-space"> </span><br><br>... and adds new problems :)<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Of course. But something to consider in the long-term.</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>> > > > That [disabling biased locking] may be an option in some cases<span class="Apple-converted-space"> </span><br>> > > > in addition to these suggested changes.<span class="Apple-converted-space"> </span><br>> > > Not sure what you mean.<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > In some cases, a "fix" to long promotion failure times might be to<span class="Apple-converted-space"> </span><br>> > disable biased locking - because biased locking may not even be<span class="Apple-converted-space"> </span><br>> > advantageous in some cases due to its own overhead.<span class="Apple-converted-space"> </span><br>> Well, if biased locking doesn’t pay off for an application (and we do<span class="Apple-converted-space"> </span><br>> have evidence that biased locking might not pay off for our<span class="Apple-converted-space"> </span><br>> services), then I assume a lot of classes will end up being unbiased<span class="Apple-converted-space"> </span><br>> and their prototype header set to 0x1 which might prevent the high<span class="Apple-converted-space"> </span><br>> amount of marks being preserved issue.<span class="Apple-converted-space"> </span><br><br>Without biased locking, no object header will be marked as biased :)<span class="Apple-converted-space"> </span><br><br>> > > > A larger segment size may be a better trade-off for current,<span class="Apple-converted-space"> </span><br>> > > > larger applications though.<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > > Is there any way to auto-tune the segment size? So, the larger<span class="Apple-converted-space"> </span><br>> > > the stack grows, the larger the segment size?<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Could be done, however is not implemented yet. And of course the<span class="Apple-converted-space"> </span><br>> > basic<span class="Apple-converted-space"> </span><br>> > promotion failure handling code is very different between the<span class="Apple-converted-space"> </span><br>> > collectors. Volunteers welcome :]<span class="Apple-converted-space"> </span><br>> I factored out some of the logic to a PreservedMarks class which can<span class="Apple-converted-space"> </span><br>> be re-used by all GCs to somewhat cut down on the code replication...<span class="Apple-converted-space"> </span><br><br>There is already OopAndOopMark or so in G1 btw that might be used<span class="Apple-converted-space"> </span><br>there.<span class="Apple-converted-space"> </span></div></div></span></blockquote></div><p><br></p><p>Way ahead of you. ;-)</p><p><br></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>[...]<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Should I create a new CR per GC (ParNew and ParallelGC) for the<span class="Apple-converted-space"> </span><br>> > > per-worker preserved mark stacks and we’ll take it from there?<span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Please do.<span class="Apple-converted-space"> </span><br>> JDK-8146989 and JDK-8146991. I’ll post a webrev for the first one<span class="Apple-converted-space"> </span><br>> later today.<span class="Apple-converted-space"> </span><br>> Tony<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> <div id="bloop_sign_1452728835127785984" 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>