I did some more research on this strange quirk, and I'm convinced that it's actually a bug in the JIT compiler used in the 32-bit Server JVM and the 64-bit JVM. The 32-bit client JVM uses a different JIT compiler which does not have this bug, so that's why the original while loop works just fine on the 32-bit client JVM. Due to this bug, the JIT Server Compiler mis-compiles the while loop and creates an infinite loop instead. Only by adding another statement inside the while loop will the buggy JIT Server Compiler compile the while loop properly. Any Java statement will work and doesn't have to be the 1ms sleep delay that I used above.
If Sun/Oracle ever fixes the JIT Server Compiler, this workaround can be removed in the future. However, a more elegant way is to refactor/replace the while-polling code with wait/notify calls which doesn't need the workaround above. But the workaround works well, and perhaps it may be a good idea to increase the delay to keep the CPU from polling too quickly than necessary. I think a delay of 250ms is good so that it only polls 4 times a second, and I'm sure people won't mind the quarter second delay after saving/loading.
If Sun/Oracle ever fixes the JIT Server Compiler, this workaround can be removed in the future. However, a more elegant way is to refactor/replace the while-polling code with wait/notify calls which doesn't need the workaround above. But the workaround works well, and perhaps it may be a good idea to increase the delay to keep the CPU from polling too quickly than necessary. I think a delay of 250ms is good so that it only polls 4 times a second, and I'm sure people won't mind the quarter second delay after saving/loading.