Re: About the volatile and MESI Protocal

--===============1506107046930491920==
Content-Type: multipart/alternative; boundary="000000000000ce109e05d8677015"

--000000000000ce109e05d8677015
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Likewise it has been discussed multiple times that this is not just an
optimisation of some obscure case.

The alternative to JMM is to have total order for all memory accesses. This
obviously does not scale with the number of CPUs. You have to define some
small number of accesses that have to be ordered totally, so that the
majority of accesses don't have total order.


Alex

On Sat, 19 Feb 2022, 23:24 Gregg Wonderly via Concurrency-interest, <
[email protected]> wrote:

> This is what compiler writers believe to be awesome optimization. It can
> invalidate software systems randomly, because the compiler can rewrite th=
e
> generated instruction stream in one branch of code when you=E2=80=99ve ma=
de changes
> in another branch.
>
> There=E2=80=99s been all kinds of fucysion about this on this list snd el=
sewhere.
> Realistically, this is why you will find most Java developers with any re=
al
> amount of experience with this problem now declare all class s ops
> variables as either final or obliterated so that the compiler will stop
> generating surprise rewrites of your logic into something that does not
> represent the readable software written.
>
> Gregg Wonderly
>
> Sent from my iPhone
>
> > On Feb 19, 2022, at 4:31 AM, Florian Weimer via Concurrency-interest <
> [email protected]> wrote:
> >
> > =EF=BB=BF* Nathan Reynolds via Concurrency-interest:
> >
> >> Without volatile or fences, JIT is free to hoist the "if (bChanged =3D=
=3D
> >> !bChanged)" out of the for loop.  If for some reason JIT decides to no=
t
> >> hoist, JIT could also load bChanged into a single register each
> iteration
> >> and then execute "if (bChanged =3D=3D !bChanged)" using the value in t=
he
> single
> >> register.  On the other hand, if JIT is smart enough, it can get rid o=
f
> the
> >> if statement and block altogether since it can never be true according
> to
> >> the Java Memory Model.  Since this is very unlike a real code scenario=
,
> I
> >> doubt JIT has been enhanced for this last case.
> >
> > I don't think this is a property of the memory model, it merely
> > follows from choices Java implementation have made regarding compiler
> > barriers for volatile field access.
> > _______________________________________________
> > Concurrency-interest mailing list
> > [email protected]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

--000000000000ce109e05d8677015
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Likewise it has been discussed multiple times that this i=
s not just an optimisation of some obscure case.<div dir=3D"auto"><br></div=
><div dir=3D"auto">The alternative to JMM is to have total order for all me=
mory accesses. This obviously does not scale with the number of CPUs. You h=
ave to define some small number of accesses that have to be ordered totally=
, so that the majority of accesses don&#39;t have total order.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Alex</di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Sat, 19 Feb 2022, 23:24 Gregg Wonderly via Concurrency-interest, &lt;<=
a href=3D"mailto:[email protected]">concurrency-interest@c=
s.oswego.edu</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is=
 what compiler writers believe to be awesome optimization. It can invalidat=
e software systems randomly, because the compiler can rewrite the generated=
 instruction stream in one branch of code when you=E2=80=99ve made changes =
in another branch.<br>
<br>
There=E2=80=99s been all kinds of fucysion about this on this list snd else=
where.=C2=A0 Realistically, this is why you will find most Java developers =
with any real amount of experience with this problem now declare all class =
s ops variables as either final or obliterated so that the compiler will st=
op generating surprise rewrites of your logic into something that does not =
represent the readable software written.<br>
<br>
Gregg Wonderly<br>
<br>
Sent from my iPhone<br>
<br>
&gt; On Feb 19, 2022, at 4:31 AM, Florian Weimer via Concurrency-interest &=
lt;<a href=3D"mailto:[email protected]" target=3D"_blank" =
rel=3D"noreferrer">[email protected]</a>&gt; wrote:<br>
&gt; <br>
&gt; =EF=BB=BF* Nathan Reynolds via Concurrency-interest:<br>
&gt; <br>
&gt;&gt; Without volatile or fences, JIT is free to hoist the &quot;if (bCh=
anged =3D=3D<br>
&gt;&gt; !bChanged)&quot; out of the for loop.=C2=A0 If for some reason JIT=
 decides to not<br>
&gt;&gt; hoist, JIT could also load bChanged into a single register each it=
eration<br>
&gt;&gt; and then execute &quot;if (bChanged =3D=3D !bChanged)&quot; using =
the value in the single<br>
&gt;&gt; register.=C2=A0 On the other hand, if JIT is smart enough, it can =
get rid of the<br>
&gt;&gt; if statement and block altogether since it can never be true accor=
ding to<br>
&gt;&gt; the Java Memory Model.=C2=A0 Since this is very unlike a real code=
 scenario, I<br>
&gt;&gt; doubt JIT has been enhanced for this last case.<br>
&gt; <br>
&gt; I don&#39;t think this is a property of the memory model, it merely<br=
>
&gt; follows from choices Java implementation have made regarding compiler<=
br>
&gt; barriers for volatile field access.<br>
&gt; _______________________________________________<br>
&gt; Concurrency-interest mailing list<br>
&gt; <a href=3D"mailto:[email protected]" target=3D"_blank=
" rel=3D"noreferrer">[email protected]</a><br>
&gt; <a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest"=
 rel=3D"noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailm=
an/listinfo/concurrency-interest</a><br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" rel=
=3D"noreferrer">[email protected]</a><br>
<a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel=
=3D"noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/l=
istinfo/concurrency-interest</a><br>
</blockquote></div>

--000000000000ce109e05d8677015--

--===============1506107046930491920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--===============1506107046930491920==--