Summary
I recently noticed in JRE1.5 that HotSpot is yanking loop controls as invariant when not marked as volatile. Have you encountered this?

The Java Memory Model was formally updated in JSE1.5 to include a strict definition and implementation of the volatile keyword. In JSE1.4, Sun had already started working on making their VM compatible with the better specification of synchronized and volatile that would be implemented in JSE1.5. Recently, I started using a P4 based laptop with Hyper-Threading, that now makes my software run in a multi-processor environment. This changes everything...

After starting to use the new machine, I noticed that I started getting bit by an optization where loop control, boolean value tests are being yanked out of the loop.

The basic structure of the problematic software is as follows.

class MyClass ... implements Runnable {
    private boolean stopping;
    public void stop() {
        stopping = true;
        // maybe close a socket etc.
    }

    public void run() {
        while( !stopping ) {
            try {
                ... do some work ...
            } catch( Exception ex ) {
                ... process exception ...
            }
        }
    }
}

What I am seeing is that HotSpot is apparently (this I have gleened from conversations on Doug Lea's Concurrency-Interest list) yanking the while( !stopping) { } block out and replacing it with an if( !stopping ) { } block surrounding a while(true) { } block!

class MyClass ... implements Runnable {
    private boolean stopping;
    public void stop() {
        stopping = true;
        // maybe close a socket etc.
    }

    public void run() {
        if( !stopping ) {
            while(true) {
                try {
                    ... do some work ...
                } catch( Exception ex ) {
                    ... process exception ...
                }
            }
        }
    }
}

The end result, of course, is that a call to stop(); will never be able to stop the looping thread executing in run(){ }.

What I've found, of course, is that if I go ahead and declare stopping as volatile that suddenly the code works as expected!

I ran this code for a long time on a single processor laptop on JSE1.5 even, and don't recall that I saw this happening. I wonder if this optimization only happens on MP machines.

So, beware... If you have been using loop controls like this and have neither made the references happen inside synchronized code, or made the variables volatile, you may be getting bit by this "optimization!"

Talk Back!

Have an opinion? Readers have already posted 5 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.