> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: OT if/else or not if/else
> Unless the JIT can prove that there are no side-effects, it's not > going to perform any speculative computations for a possible branch. True, but due to inlining of many methods, the side effects are often visible. It's quite common for compilers to generate reads out of order when it can be proven they are not impacted by any subsequent write operations. > it's not easy to decide if either of those two methods have any > side-effects. Actually, given the JVM architecture, it is quite easy - the compiler (the real one, not javac) has the callee method implementation available when it's processing the caller. This is not true with most languages. If a subsequent class definition invalidates such a determination, the compiler deoptimizes the generated method, and, if needed, recompiles it. > If the method is private or final in the declared type, > it can be evaluated completely, but that's a somewhat rare case. Nope (see above). > Presumably, the if-without-else case would actually free the compiler > to evaluate those predicates "early", but that wouldn't be considered > "speculative" in my mind because those side-effects would have > happened anyway (since all branches will be evaluated). Only certain reads can be issued in such instances, since any writes are expected to be in order (unless you're dealing with the rather bonkers C++ memory model). The predicate evaluation isn't speculative, but reads from inside the predicated area are often lifted out of the blocks, and it's these that are speculative. > The only potential problem would be with an early branch that throws an > exception, in which case any side-effects of a later predicate would > be ... surprising. If a predicate evaluation might cause a write, it pretty much precludes looking at them out of order. - Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
