HI guys!

maybe what I'm asking could sound like a very naive question, but in recent 
times I've found very problematic to understand if exists a "rule of thumb" 
to find out how the JVM (or replace it with anything SW/HW-wise that could 
mess with the order of the statements of your program) manage reordering of 
operations in case of single threaded execution. 

As a general rule I've always applied that the order *would appear* as the 
program order shows, but this implied that writing over a (regular Direct 
or array-based) ByteBuffer with a particular order is different than doing 
it against a MappedByteBuffer.
That rule has lead me, for example, to use explicit fences (for single 
threaded program too) as a mean to put "lines on the sands" and be sure 
that the compiler would access data in the order I'm expecting it will do 
it.

This perception is enforced further after reading (and if I've understood 
it) the article 
<http://grothoff.org/christian/teaching/2007/3353/papers/click95simple.pdf> 
from Cliff Click about "Sea of nodes" in which *every* operation on Memory 
Mapped I/O will produce a new I/O state and that prevents any reordering 
between the 2 kind of operations (LOAD and STORE), while the others are 
treated only respecting data dependencies (in theory, there is no limit on 
reordering!!!!).
I'm missing something for sure, because if it was true, any 
(single-threaded) "protocol" that rely on the order of writes/loads against 
(not mapped) ByteBuffers to be fast (ie: sequential writes rocks :P) risks 
to not see the order respected if not using patterns that force the 
compiler to block the re-ordering of such instructions (Sci-Fi hypothesis).
A. Shipilev (on twitter) has pointed me to look at gcm.cpp 
<http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/2c3130311ffa/src/share/vm/opto/gcm.cpp>
 to 
understand better what reordering are allowed to happen...but I'm not 
feeling confident to have understood it properly.
I'm not even sure that building an empiric experiment and reading the 
produced ASM could prove something useful, if not what could happen for a 
very specific case (and a very specific strong memory model, the one of my 
laptop x86 CPU).
What do you think?

with great regards,
Francesco

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to