As summary: difference between ”server” and ”client” JVM *can* cause big surprises in badly coded thread stop conditions. Additionally other random synchronized blocks can cause unpredictability in behaviour.
I tested sample program, and there really was this big difference between ”-client” and ”-server”. Changing ”stopRequested” to be volatile caused consistent behaviour in both JVMs. And no, my computer isn’t even having fancy multithreaded or multicore CPU.
Naturally this issue concerns not only stop condition of the thread, but all member fields accessed from the worker thread. If there is no sync, then worker thread is not seeing changes in the values immediately.
So, you have been warned. Don’t trust into those pesky non-synced stop flags to work, or you will be bitten by ”but it worked in my computer…” syndrome.
Note: Of course this ”proof of the problem” test program is a bit flawed. Server JVM is doing high optimization for the loop construct, and thus doesn’t check change of the field, since there isn’t some ”sync” to enforce such. However, such buzy loops without some random syncronization block to occur are rather rare in normal worker threads.