On 12/17/2013 7:42 AM, Gregg Wonderly wrote:
...
As I’ve discussed here before, one of the most destructive
activities
that has happened in the JDK, has been the “enforcement” of “volatile”
vs “non-volatile” correctness in the activities of the JIT. The standing
example, is this:
class foo implements Runnable {
bool done;
public void run() {
while(!done) {
doAllTheWork();
}
}
public void stop() {
done = true;
}
}
In JDK 1.4 and before, this class would function correctly on single
processor machines (which most developers used), and would hardly ever
exhibit a “bug” on multi-core and multi-processor machines. In JDK 5 and
later, the JIT rewrites this class to look like
class foo implements Runnable {
bool done;
public void run() {
if(!done) {
while( true ) {
doAllTheWork();
}
}
}
public void stop() {
done = true;
}
}
...
It’s amazingly frustrating and has made Java a very complex language
to use, because the focus is first on “all out performance” and not
on “developer success”.
I disagree with this summary.
The effect of the JIT change, in addition to improving performance for
correct code, is to make missing volatile declarations much more
visible. It is likely to make the difference between a bug that happens
in a day of simple regression testing and one that happens much less
frequently, and only on some multiprocessor hardware configurations.
Counting on uniprocessor-only is rapidly becoming unrealistic. Ideas for
using chip space, or additional chips on a board, to add performance are
running out of steam. Most hardware performance gains will have to come
from more processors. Even if a developer does some of their work on a
uniprocessor, they should expect their code to be used on multiprocessors.
I've debugged a problem that happened about once a week if a particular
workload was run on at least 50 processors, and it is one of the most
technically difficult and frustrating tasks I've ever done - and I had
access to resources that most software developers do not have.
Converting a "hardly-ever" failure to one that is likely to show up
often enough to be easy to detect and debug, even on a uniprocessor, is
highly positive for developer success. It enables changing "hardly-ever"
to "never".
Patricia
