This is indeed what I was expecting...While others archs (PowerPC , tons of ARMs and the legendary Alpha DEC) are allowed to be pretty creative in matter of reordering...And that's the core of my question: how much a developer could rely on the fact that a compiler ( or the underline HW) will respect the memory access that he has put into the code without using any fences?The answer is really a "depends on the compiler/architecture"?Or exist common high level patterns respected by the "most" of compilers/architectures?
Il lun 16 gen 2017, 22:14 Vitaly Davidovich <vita...@gmail.com> ha scritto: > Depends on which hardware. For instance, x86/64 is very specific about > what memory operations can be reordered (for cacheable operations), and two > stores aren't reordered. The only reordering is stores followed by loads, > where the load can appear to reorder with the preceding store. > > On Mon, Jan 16, 2017 at 4:02 PM Dave Cheney <d...@cheney.net> wrote: > > Doesn't hardware already reorder memory writes along 64 byte boundaries? > They're called cache lines. > > > Dave > > > > On Tue, 17 Jan 2017, 05:35 Tavian Barnes <taviana...@gmail.com> wrote: > > On Monday, 16 January 2017 12:38:01 UTC-5, Francesco Nigro wrote: > > 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). > > > I don't think you're missing anything. The JVM would be stupid to reorder > your sequential writes into random writes, but it's perfectly within its > right to do so for a single-threaded program according to the JMM, as long > as it respects data dependencies (AFAIK). Of course, that would be a huge > quality of implementation issue, but that's an entirely separate class from > correctness issues. > > > 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. > > > > > > > > > > > -- > > > 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. > > > -- > Sent from my phone > > -- > You received this message because you are subscribed to a topic in the > Google Groups "mechanical-sympathy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/mechanical-sympathy/EMIBqjX4uzk/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > mechanical-sympathy+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
