Make load/store of 64-bit long and double atomic

[John Crowley]

All:

Would like to make a suggestion re the JVM and non-atomic load/store for long and double values since both are 64-bit.  (Sec 17.7 of the JLS version 8 - have not been able to find a JLS V9 yet). Did some searching through JSRs and mailing lists, but did not see this addressed - please send me a link if it has been and I just missed it.

Right now, in a multi-threaded environment the developer must make these volatile to ensure correct operation - which I would suspect that 95% of Java developers do not realize. (I certainly didn’t for over 20 years!)

Worse, in most cases these will in fact be atomic on any 64-bit server, and non-atomic on a 32-bit architecture - so you may suddenly get very strange differences running the same codebase. [Are there any 64-bit JVMs in which these load/store operations are done in 32-bit chunks?]

I would propose pushing this decision down into the JVM - along roughly this plan:

Define a new JVM option:  -DatomicLong=[true|false]
For any JVM with a 64-bit architecture this would be ignored (or issue a warning if explicitly set to false)
For a 32-bit JVM, the default would be false (see below)
If true for a 32-bit JVM, then the JVM itself would execute a memory barrier as required to perform atomic load/store of a long or double from/to application memory.

A JVM option is suggested because there are probably still many applications running on 32-bit servers, and using a lot of long/double variables, that would suffer a major performance hit if the 32-bit JVM suddenly started implementing atomic load/store operations. Examples: financial models, simulations, weather forecasting. Also many applications may not be multi-threaded and would prefer to eliminate the overhead.

Having a default of false preserves the current semantics of a 32-bit JVM. 

You could also drop the JVM option and have 32-bit JVMs compiled with two flavors: JVM (old semantics) and JVMAtomic (new semantics). This would eliminate any possible runtime overhead and allow the user to invoke the desired version at runtime.

Best,


John Crowley
Westport, CT
203-856-2396