tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: OT if/else or not if/else
Date Tue, 26 Apr 2016 19:26:07 GMT

On 4/26/16 12:18 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [] 
>> 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.

The compiler would have to invalidate that side-effect cache every time
a new class was used for that particular shouldDoSomething method gets
called, since it could be overridden at any time, so the callee's method
cannot (always) be known in advance. This is why, below, I mentioned
private and final methods. Those are known knowns, so coin a phrase.

I've never written a compiler (JIT) and all of these things are great
optimizations if they don't become bottlenecks, but I guess it's up to
the compiler writers to decide when enough is enough. Then again, JIT
work is constantly being done, so I suppose these days, they are quite
smart. When you gotta compete with native C, the JIT had better be good ;)

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

Agreed. I was more concerned with writes. Any time you can have your CPU
doing anything other than NOPs, you should be. Speculative reads are
pretty much always a good idea.

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

Exactly. This just goes back to how much work the compiler (JIT) is
willing to investigate and how complex the predicate (or branch itself)
might actually be. Because not only must the predicates be read-only,
anything you might want to execute ahead of time within the branch needs
to be read-only as well.

The smarter the compiler, the better performance you can get. Compilers
these days are strikingly smart, and can prove things that even the most
seasoned high-level-language (e.g. Java) programmer might stay away from
because it's risky, or perhaps just plain difficult to read. That's one
of the great things about languages with JITs (instead of
pre-processors) instead of traditional compilers (e.g. C): the JIT can
take nice, maintainable, good-looking code and turn it into a complete
mess of internal code that has equivalent runtime meaning, but with
better performance than a naive or straightforward implementation of the
high-level language.

I like Olaf's saw: "optimize for the maintainer, not the compiler." The
compiler is smarter than you, anyway, so you may as well write your code
so that humans can understand it. ;)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message