At this point I tend to agree with Ylong and Jeremy. I’m very far from being an expert but I thought 14.2 meant that the result of execution of a single thread had to be the same as if it executed the given instructions in the order supplied. I didn’t think it meant it had to execute those particular instructions, I thought it could pick whatever instructions it wanted as long as the result would be the same as if the given instructions were executed in the given order. If there’s only one thread, Jeremy’s transformed code obviously produces the same result as the original. To me saying it ‘has different logic” and “has a timing window” might be true but don’t directly mean that if violates the ch. 14 semantics.
Hoping to learn more…. david jencks > On Sep 15, 2015, at 9:58 PM, Yilong Li <yilong...@runtimeverification.com> > wrote: > > Your argument seems to assume that reordering is the only code > transformation that can be done by compiler or hardware. I don't agree that > you call this transformation a red herring. It might not be practical but > it's certainly valid. Does it violate the intra-thread semantics you > mentioned in JLS Chaptor 14? No. Is it possible for the transformed method > to return 0? Yes. > > Yilong > > On Tue, Sep 15, 2015 at 6:39 PM, Caldarale, Charles R < > chuck.caldar...@unisys.com> wrote: > >>> From: David Jencks [mailto:david_jen...@yahoo.com.INVALID] >>> Subject: Re: RV-Predict bugs >> >>> I have been having a hard time believing the reordering claims, but >> finally I went to Jeremy's >>> blog post. To recap, he says >> >>> if (hash == 0) { >>> int h = //compute hash >>> hash = h; >>> } >>> return hash; >> >>> can be reordered to >> >>> r1 = hash; >>> if (hash == 0) { >>> r1 = hash = // calculate hash >>> } >>> return r1; >> >>> Obviously this last version is susceptible to returning 0. >> >>> It looks to me like the 2nd version is not a reordering of the java >> statements of the first version. >> >> Correct; it's different logic, and thus a bit of a red herring. It >> introduces a timing window not present in the original code; it's not an >> example of a speculative read. >> >> - Chuck >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you >> received this in error, please contact the sender and delete the e-mail and >> its attachments from all computers. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
