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 > >
