> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: RV-Predict bugs
> I discovered that within a synchronized block, the JIT is allowed to re-order > statements if it determines it is safe to do so -- and that statements that > occur before the memory barrier must not be interleaved with statements > inside > the block, and likewise, nothing after the block can be moved "inside" that > block. Correct, mostly; the exceptions are that operations that can be proven to not have any dependencies on those within the block could theoretically be moved to inside or prior to the block (but compilers generally won't bother to do that when there's a memory barrier). > But it seems reasonable that the JIT would be allowed to perform some > otherwise "conditional" code execution *before* the condition is > actually evaluated, as long as that code doesn't have any side-effects > (such as assignment of the return value of, say, hashCode() or > StringManager.getString()). Yes, speculative executions are allowed, as long as program order isn't violated. > I'm sure the rules for "side-effects" include calling methods not yet proven > to > have any side-effects which might be a giant rathole that nobody has decided > to > jump into, and therefore method calls are always considered "side effects" > just > to keep things safe and simple. Nope. I spend much of my time inside LLVM these days, and a significant chunk of optimizations can be enabled when functions are known not to have side effects. There's a lot of effort put into annotating function declarations to let the compiler know that they're safe. - 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
