Re: About the volatile and MESI Protocal

--===============1146835111221716669==
Content-Type: multipart/alternative; boundary="000000000000f9a0fb05d85cb6ac"

--000000000000f9a0fb05d85cb6ac
Content-Type: text/plain; charset="UTF-8"

The placement of memory and compiler barriers by a conforming
implementation of the JVM is driven by memory model.

There are things you can choose, but there are mathematical properties that
the choices must satisfy.

In this case no visibility of mutation is required by the memory model, so
it is allowed to reduce the code to the form that behaves like such that
only sees the changes done by the same thread. Which means bChanged can be
kept in a register, and even the condition check is allowed to be
eliminated like dead code. But you have to keep the loop, as the progress
or lack thereof is a sideeffect that we must heed.

Alex

On Sat, 19 Feb 2022, 10:30 Florian Weimer, <[email protected]> wrote:

> * Nathan Reynolds via Concurrency-interest:
>
> > Without volatile or fences, JIT is free to hoist the "if (bChanged ==
> > !bChanged)" out of the for loop.  If for some reason JIT decides to not
> > hoist, JIT could also load bChanged into a single register each iteration
> > and then execute "if (bChanged == !bChanged)" using the value in the
> single
> > register.  On the other hand, if JIT is smart enough, it can get rid of
> 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.
>

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

<div dir=3D"auto">The placement of memory and compiler barriers by a confor=
ming implementation of the JVM is driven by memory model.<div dir=3D"auto">=
<br></div><div dir=3D"auto">There are things you can choose, but there are =
mathematical properties that the choices must satisfy.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">In this case no visibility of mutation is re=
quired by the memory model, so it is allowed to reduce the code to the form=
 that behaves like such that only sees the changes done by the same thread.=
 Which means bChanged can be kept in a register, and even the condition che=
ck is allowed to be eliminated like dead code. But you have to keep the loo=
p, as the progress or lack thereof is a sideeffect that we must heed.<br><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Alex</div></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 19 Feb =
2022, 10:30 Florian Weimer, &lt;<a href=3D"mailto:[email protected]">fw@dene=
b.enyo.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Nathan=
 Reynolds via Concurrency-interest:<br>
<br>
&gt; Without volatile or fences, JIT is free to hoist the &quot;if (bChange=
d =3D=3D<br>
&gt; !bChanged)&quot; out of the for loop.=C2=A0 If for some reason JIT dec=
ides to not<br>
&gt; hoist, JIT could also load bChanged into a single register each iterat=
ion<br>
&gt; and then execute &quot;if (bChanged =3D=3D !bChanged)&quot; using the =
value in the single<br>
&gt; register.=C2=A0 On the other hand, if JIT is smart enough, it can get =
rid of the<br>
&gt; if statement and block altogether since it can never be true according=
 to<br>
&gt; the Java Memory Model.=C2=A0 Since this is very unlike a real code sce=
nario, I<br>
&gt; doubt JIT has been enhanced for this last case.<br>
<br>
I don&#39;t think this is a property of the memory model, it merely<br>
follows from choices Java implementation have made regarding compiler<br>
barriers for volatile field access.<br>
</blockquote></div>

--000000000000f9a0fb05d85cb6ac--

--===============1146835111221716669==
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

--===============1146835111221716669==--