<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Okay.  Can you tell me the relevance of this, though?</span></blockquote><div><br></div><div>Relevance is if code works correctly in interpreter then, practically speaking, compiler tries to not break it.  Of course this isn't always the case (e.g. compiler hoisting reads of a non-volatile field that should be volatile), but is generally true. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Or simply determine that nothing depends on position, so an update to<br></span><span style="font-size:12.8px">it doesn't have to be generated.</span></blockquote><div><br></div><div>This is irrelevant.  There are, today, artifacts the optimizer leaves behind even if it eliminates certain other operations to preserve behavior, warranted by spec or simply being cautious about breaking code.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Not really: the JMM determines what is possible.  It's not just<br></span><span style="font-size:12.8px">"anything".</span></blockquote><div><br></div><div>Yes, "anything" was hyperbole.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">It might already have happened.  The problem with reasoning in such a<br></span><span style="font-size:12.8px">fragile way is that things get broken by accident.  The current Unsafe<br></span><span style="font-size:12.8px">support works by accident: as we have seen, copyMemory works because<br></span><span style="font-size:12.8px">position is updated after the call to Unsafe.  People who are<br></span><span style="font-size:12.8px">reasoning in terms of the compiler don't necessarily think of all the<br></span><span style="font-size:12.8px">incorrect things library authors might have done.</span></blockquote><div><br></div><div>There are other operations in DBB that touch native memory that appear to work without any position update (i.e. the various getters).  Again, I'm not advocating reasoning like this for new code that someone may write.  The thread started with Alexandre asking a question for which he then added a segfaulting example; we tried to figure out why his didn't work and DBB works.  By definition, this is speculation unless you're expecting me to provide a full trace through the compiler optimization pipeline.  At no point did I advise/suggest that someone should reason like this for their code, I was merely trying to use educated guesses as to why it works keeping compiler optimizations in mind.</div><div><br></div><div>As to the theoretical vs practical aspect, I agree that there's nothing holding this together spec/theory wise; afterall, I'm quite happy that reachabilityFence is being added (don't particularly like that name, but whatever).  But if you create a spec conforming JVM implementation today that segfaults in DBB, congrats but nobody is going to use it.  Moreover, once reachabilityFence is added and sprinkled in all the appropriate JDK places, there may be a time when someone advertently or inadvertently makes a compiler optimization that will break DBB-like clones in user code.  My hunch, given the mindset of java and emphasis on not breaking code, even code that's misbehaved and not conforming to spec, is that such optimization will not go forward.  There are already cases where JVM treads carefully to cater to java code out in the wild; the fact that final fields are not treated as constants due to fear of reflection updates is a prime example which actually could have tangible performance benefits if it weren't so.  AFAIK, there's nothing in the spec that states it's legal to update final fields.</div><div><br></div><div>We can agree on the spec all we want, but the reality/practical aspects are more nuanced. </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 10:17 AM, Andrew Haley <span dir="ltr"><<a href="mailto:aph@redhat.com" target="_blank">aph@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/08/2015 02:40 PM, Vitaly Davidovich wrote:<br>
>><br>
>> The lifetime, natural or otherwise, of an instance does not survive<br>
>> until an instance method returns because, a lot of the time, that<br>
>> instance method is inlined.<br>
><br>
> You're talking about optimization here (inlining); by "natural" I<br>
> meant the naive/no optimization case (e.g. interpreter, debugger<br>
> attached w/breakpoint in method, etc).<br>
<br>
</span>Okay.  Can you tell me the relevance of this, though?<br>
<span class=""><br>
> It's not just HotSpot, though: some VMs are even more aggressive, and<br>
><br>
> Which java VMs are these? Just curious.<br>
<br>
</span>IBM's J9.<br>
<span class=""><br>
>> we have seen finalizers executed even before constructors have<br>
>> completed.  And that is allowed by the specification.<br>
><br>
> Ok, but that's beside the point, really.  Surely if compiler can<br>
> optimize and arrange for liveness to allow for it, then it's a good<br>
> thing it does that.  My point isn't that this cannot happen due to<br>
> spec, but rather that in places like DBB where `this` is used after<br>
> the Unsafe call the compiler has to schedule things differently in<br>
> order to reduce lifetime.<br>
<br>
</span>Or simply determine that nothing depends on position, so an update to<br>
it doesn't have to be generated.<br>
<span class=""><br>
> And my point is that compilers generally tend to be cautious in<br>
> doing things that may break code.  This is the practical aspect we<br>
> were referring to - it's actual humans writing these optimizations,<br>
> and they're sensitive to breaking code, particularly in java.<br>
> Theoretically, yes, anything is possible.<br>
<br>
</span>Not really: the JMM determines what is possible.  It's not just<br>
"anything".<br>
<span class=""><br>
> It's already broken.  Sure.  Now try to submit a patch to Hotspot<br>
> that will break this case, even if allowed by spec, and see how far<br>
> you get :).<br>
<br>
</span>It might already have happened.  The problem with reasoning in such a<br>
fragile way is that things get broken by accident.  The current Unsafe<br>
support works by accident: as we have seen, copyMemory works because<br>
position is updated after the call to Unsafe.  People who are<br>
reasoning in terms of the compiler don't necessarily think of all the<br>
incorrect things library authors might have done.<br>
<span class="HOEnZb"><font color="#888888"><br>
Andrew.<br>
</font></span></blockquote></div><br></div>