It is well known that Java Language allows compliers to re-arrange lines of compiled code as long as the re-order makes no difference to the code semantics. However , the compiler is required to only bother about sematics as seen from the current thread. If this re-order affects semantics in a multithreaded situation , it usually causes concurrency issues ( memory visibility )
My question(s) :
-
What is achieved by allowing this freedm to the compiler ? Is it really possible for the compiler to produce code which is more efficient by rearranging the code ? I am yet to see a practical case for this. I feel sometimes that the benefits if any are far outweighed by the concurrency risks this can introduce.
-
Is there any way that programmer can tell compiler not to rearrange lines like this ? I know that using synchronization primitives effectively handles the side-effects of rearranging , but I am asking if there is any direct way ( compiler option ) to turn this off ?
The
javaccompiler has performs next to no optimisations.The JIT native compiler could re-order instructions where there is a memory ordering problem. However, the CPU also can re-order instructions and memory updates which have the same effect.
The main benefit is code portability. The more guarantees you provide, the more difficult it is to ensure every platform actually does this.
There is also a significant performance improvement by allowing the CPU to execute instructions as and when it can rather than in a strict order.
Yes. but the re-ordering done by the CPU is more significant.
This is why you use memory barriers like
volatile,synchronizedblocks andLock. When you use these you get thread safety guarantees.You can turn off the JIT, but most re-ordering is done by the CPU so it wouldn’t achieve much.
Avoiding re-ordering of updates is such a small part of the thread safety problem (its biggest issue is that is obscure and rarely occurs which makes testing it hard) And once you write thread safe code, this is alleviated.