thanks :)
W dniu poniedziałek, 16 października 2017 22:47:07 UTC+2 użytkownik Gil
Tene napisał:
>
> The bytecode doesn't matter. It's not the javac compiler that will be
> doing the optimizations you should be worried about. It's the JIT compilers
> in the JVM. The javac-generated bytecode is
The bytecode doesn't matter. It's not the javac compiler that will be doing
the optimizations you should be worried about. It's the JIT compilers in
the JVM. The javac-generated bytecode is only executed by the interpreter.
The bytecode is eventually transformed to machine code by the JIT
Thanks Gil Tene!
You obviously right. The read is not volatile so the compiler is allowed to
reorder it. Moreover, the read is not volatile, so the compiler assumes
that noone changes the source of getInt(). So, it can hoist out curr.
The last question (sorry for being inquisitive) is:
Ok. So the question below (ignoring other optimizations in the JVM that are
specific to this method) is "If I were doing this myself in some other
method, would this logic be valid if Unsafe.getIntVolatile() could be be
replaced with Unsafe.getInt()?"
The answer IMO is "no".
The issue here is
A simple answer would be that the field is treated by the method as a
volatile, and the code is simply staying consistent with that notion. Is an
optimization possible here? Possibly and Probably. But does it matter?
No. The source code involved is not performance critical, and is not worth
Hello
it is an implementation from sun.misc.Unsafe.
public final int getAndAddInt(Object ptr, long offset, int value) {
int curr;
do {
curr = this.getIntVolatile(ptr, offset); (1)
} while(!this.compareAndSwapInt(ptr, offset, curr, curr + value)); (2)
return curr;}
Why there is
