Is there a worst case implementation of the JVM?

The Java memory model makes it clear what can and cannot be assumed about how threads interact through memory. For example, if one thread writes a new value to a field without appropriate synchronization then the new value is not guaranteed to be observable by other threads. In practice, however, other threads might anyhow read the new value in spite of inadequate synchronization, depending on time between write and read, hardware architecture, etc.

This can lead to bugs that are hard to discover and difficult to reproduce. It could therefore be useful to run a java application on a worst case JVM that did absolutely no memory synchronization between threads beyond the guarantees in the Java memory model. Does such a worst case JVM implementation exist?

From stackoverflow

• You could try using Terracotta to cluster your program. It is incredibly unforgiving around incorrect synchronization (which will become apparent even with only one node in the cluster). This is a great question: I've often wanted exactly this ability - I'm surprised there's not a switch in the standard JRE -XXJMMExtreme

  Terracotta is open-source and free for the basic product.

• I don't know of any VM which guarantees worst case behavior all the time, which seems to be what you are asking for. The situation that you are describing can occur with Sun VMs (as well as many others), but only due to caching issues. I'm not familiar with a VM that intentionally does this all of the time.

• This might help: http://javapathfinder.sourceforge.net/

• There are many ways which could trigger a concurrency bug.

  • Load your application to many more threads than you would normally expect. Make sure this is more than enough to get 99%+ CPU.
  • Run your program with a profiler enabled or the JIT disabled. This changes the timing behaviour of your application.
  • Test both Java 5 and Java 6 (This is often the simplest and the best way to find a few bugs) I have not found a bug using Java 7 which didn't appear in 5/6.

  For worst case JVM, try a mobile phone. (Your application probably won't work at all) ;)