Java memory model question

[Hans Boehm]

On Fri, Mar 6, 2020 at 5:52 AM Andrew Haley <aph at redhat.com> wrote:

> On 3/6/20 10:27 AM, Luke Hutchison wrote:
> > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> >> No, but  this is a common myth.  Method boundaries are not part of the
> >> JMM, and the JIT regularly makes optimizations that have the effect of
> >> reordering operations across method boundaries.
> >
> > Thanks. That's pretty interesting, but I can't think of an optimization
> > that would have that effect. Can you give an example?
>
> Inside an optimizer in intermediate form, unrelated operations are
> often unordered: that is to say, they may be emitted in any order.
>
> We should also mention that a lot of hardware is very happy to reorder
memory accesses across method boundaries. If the method was inlined,
or in the event of a tail call, those may no longer even be visible at that
point.

Be careful with spurious insertions of "volatile", even where that's
possible.
It may have a large performance impact. On x86, it may not be that bad,
since it primarily affects stores. On some architectures, it also affects
loads a lot.
(Java volatile is very different from C and C++ volatile, which has much
less
impact on performance, and officially has nothing to do with threads.)

I haven't searched through the documentation, but currently this sounds
to me like a streams documentation bug. Streams operations must
clearly ensure the necessary ordering.