<div dir="ltr">><span style="font-size:12.8px">There was also another thread a few months back where I was asking why a small local array allocation wasn't scalarized, and the answer there was ordering between loop unrolling and EA passes (I can dig up that thread if you're interested). </span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It would be very nice, please -- I've tried to google it by myself (because you've noted it already in the thread) but wasn't able to guess right keywords :) </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-13 22:44 GMT+03:00 Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 13, 2016 at 3:32 PM, Ruslan Cheremin <span dir="ltr"><<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>><span style="font-size:12.8px">how it can be made stable to the point where you can rely/depend on it for performance.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Well, same can be said about any JIT optimization -- (may be it is time to rename dynamic runtime to stochastic runtime?). Personally I see SR to be the same order of stability as inlining. Actually, apart from few SR-specific issues (like with merge points), EA/SR mostly follow inlining: if you have enough scope inlined you'll have, say, </span><span style="font-size:12.8px">80%</span><span style="font-size:12.8px"> chance of SR. From my perspective it is inlining which is so surprisingly unstable.</span></div></div></blockquote></span><div>Yeah, I'd agree.  The difference, in my mind, is failing to inline a function may not have as drastic performance implications as failing to eliminate temporaries. </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">BTW: have you considered to share you experience with EA/SR pitfalls? Even if "increase likelihood" is the best option available -- there are still very little information about it in the net. </span></div></div></blockquote></span><div>I'm kind of doing that via the few emails on this list :).  I think you pretty much covered the biggest (apparent) flake in the equation - inlining, which can fail for all sorts of different reasons.  Beyond that, there's the control flow insensitive aspect of the EA, which is tangentially related to inlining (or lack thereof).</div><div><br></div><div>There was also another thread a few months back where I was asking why a small local array allocation wasn't scalarized, and the answer there was ordering between loop unrolling and EA passes (I can dig up that thread if you're interested).  The bizarre thing there was the loop operation was folded into a constant, and the compiled method was returning a constant value, but the array allocation was left behind (although it wasn't needed).</div><div><br></div><div>I agree that there isn't much information about EA in Hotspot (there's a lot of handwaving and inaccuracies online).  In particular, it'd be nice if the performance wiki had a section on making user code play well with EA (just like it has guidance on some other JIT aspects currently).</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">----</span></div><div><span style="font-size:12.8px">Ruslan</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-13 21:33 GMT+03:00 Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Sep 13, 2016 at 2:25 PM, Ruslan Cheremin <span dir="ltr"><<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>><span style="font-size:12.8px">That's my understanding as well (and matches what I'm seeing in some synthetic test harnesses). </span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Ok, I just tried to clear it out, because it is not the first time I see BCEA... noted in context of scalar replacement, and I start to doubt my eyes :)<br><br>></span><span style="font-size:12.8px">t's pretty brittle, sadly, and more importantly, unstable.<br></span><span style="font-size:12.8px"><br>Making similar experiments I see the same. E.g. HashMap.get(TupleKey) lookup can be successfully scalarized 99% cases, but scalarization become broken once with slightly changed key generation schema -- because hashcodes distribution becomes worse, and HashMap buckets start to convert themself to TreeBins, and TreeBins code is much harder task for EA. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Another can of worms is mismatch between different inlining heuristics. E.g. FreqInlineSize and InlineSmallCode thresholds may give different decision for the same piece of code, and taken inlining decision depends on was method already compiled or not -- which depends on thinnest details of initialization order and execution profile. This scenarios becomes rare in 1.8 with InlineSmallCode increased, but I'm not sure they are gone...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Currently, I'm starting to think code needs to be specifically written for EA/SR in mind to be more-or-less stably scalarized. I.e. you can't get it for free (or it will be unstable).</span></div></div></blockquote></span><div>I'm not sure this is practical, to be honest, at least for a big enough application.  I've long considered EA (and scalar replacement) as a bonus optimization, and never to rely on it if the allocations would hurt otherwise.  I'm just a bit surprised *just* how unstable it appears to be, in the "simplest" of cases.</div><div><br></div><div>I think code can be written to increase likelihood of scalar replacement, but I just can't see how it can be made stable to the point where you can rely/depend on it for performance.</div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">----</span></div><div><span style="font-size:12.8px">Ruslan <br><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-13 20:51 GMT+03:00 Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br><br>On Tuesday, September 13, 2016, Cheremin Ruslan <<a href="mailto:cheremin@gmail.com" target="_blank">cheremin@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I'm seeing some code that iterates over a ConcurrentHashMap's entrySet that allocates tens of GB of CHM$MapEntry objects even though they don't escape<br>
<br>
<br>
I'm a bit confused: I was sure BCEA-style params do affect EA, but don't affect scalar replacement. With bcEscapeAnalyser you can get (sort of) inter-procedural EA, but this only allows you to have more allocations identified as ArgEscape instead of GlobalEscape. But you can't get more NoEscape without real inlining. ArgEscape (afaik) is used only for synchronization removals in HotSpot, not for scalar replacements.<br>
<br>
Am I incorrect?</blockquote></span><div>That's my understanding as well (and matches what I'm seeing in some synthetic test harnesses). </div><div><br></div><div>I'm generally seeing a lot of variability in scalar replacement in particular, all driven by profile data.  HashMap<Integer, ...>::get(int) sometimes works at eliminating the box and sometimes doesn't - the difference appears to be whether Integer::equals is inlined or not, which in turn depends on whether the lookup finds something or not and whether the number of successful lookups reaches compilation threshold. It's pretty brittle, sadly, and more importantly, unstable.<span></span></div><div><br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
----<br>
Ruslan</blockquote><span><font color="#888888"><br><br>-- <br>Sent from my phone<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>