Re: Are there real use cases with the Java access modes?

--===============2070885152355132238==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_06BD594C-44BF-47C7-B4FE-DF4D90A2FC19"


--Apple-Mail=_06BD594C-44BF-47C7-B4FE-DF4D90A2FC19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 26, 2021, at 11:46 PM, Alex Otenko <[email protected]> =
wrote:
>=20
> Well, you made a statement that the hoist of this kind never happens =
in C. It's not true. All I did is found a bizarre example where even =
worse things happen.

You are calling them worse. They are at least debuggable.  You can use =
cc -S to stare at the code generated and see that the loop disappears.

I said this example was not the same because it=E2=80=99s a logic error =
that can be debugged to understand what is happening.  I'd take a C/C++ =
program and compile it with -g to have symbol and line number =
information.  This allows you to debug this code. The optimizer =
disappears from view and the loop comes back.  What I stated about C++ =
specifically is that the loop control expression is not hoisted out of =
the loop and evaluated once, turning the loop into a while(true){} =
condition that never exits and which a debugger can never show you the =
problem because it=E2=80=99s not a logic or data race, it=E2=80=99s an =
optimization that invalidates the way the code is written.

If the dev adds logging or other printing debugging, the JIT stops the =
hoist in many cases, and thus it looks like something is happening with =
the =E2=80=9Ccompiler=E2=80=9D breaking the code, which it is.  But, the =
user has no idea that =E2=80=98volatile=E2=80=99 is required unless =
they=E2=80=99ve had exposure to the details around the whole set of =
optimizations with fences, cache lines and the like.   I am contesting =
that being a precursor to getting working code, plain and simple.  Why =
is understanding hardware ever a consideration for correct logic to =
operate?  Optimization yes, working code, I feel it=E2=80=99s really a =
detracting =E2=80=98feature=E2=80=99 of the JIT.

Gregg

>=20
> On Mon, 26 Jul 2021, 23:27 Gregg Wonderly, <[email protected] =
<mailto:[email protected]>> wrote:
>=20
>=20
> > On Jul 26, 2021, at 2:06 AM, Alex Otenko via Concurrency-interest =
<[email protected] =
<mailto:[email protected]>> wrote:
> >=20
> > "Don't write the code like that" is what the others said about =
while(!done), so maybe you can see the point they are making.
> >=20
> > As for this example - please take it as an example of code that may =
not behave as written.
> >=20
> > As to why it is written like that - well, it is derived from a more =
elaborate mutually recursive case (with a bug).
> >=20
> > It is perfectly normal to state "zero is even", "x+1 is even, if x =
is odd", and "x+1 is odd, if x is even". This is a recursive definition =
that is derived from a recursive definition of natural numbers. It is =
not complete, but you can't tell if you don't have the compiler that =
will tell you that.
> >=20
> > So you have:
> >=20
> > char odd(int x){return even(x-1);}
> > char even(int x){return !x || odd(x-1);}
> >=20
> > Inline even into odd, do tail call optimization, and you end up with =
a loop like that (ok, x--, not x++). Both of these steps is what modern =
clang, gcc and llvm do
>=20
> Yes, but this is broken because you can only call even() on evens and =
odd() on odds for it to work.  But the tail recursion resolution on a -O =
compilation never loops and just results in a bogus =E2=80=981=E2=80=99 =
return for all cases.  With -g, you get infinite recursion that crashes =
with a stack explosion.  You can debug this and see what=E2=80=99s =
happening.
>=20
> I=E2=80=99m still completely focused on the fact that the hoist of the =
loop condition makes the code into an infinite loop that you can=E2=80=99t=
 observe, readily, why a value of done=3Dtrue doesn=E2=80=99t cause the =
loop to exit.  What you can observe in the value of done should cause =
the loop to exit.  It=E2=80=99s subtly different in my consideration, =
but it looks like its a bug because you can=E2=80=99t see the code that =
is executing incorrectly.  With this example you show, you can put =
printf in even() and odd(), see the values of x, and notice how you end =
up in odd() with x=3D=3D0 when you call even() with an odd value or =
odd() with an even value and thus the bug occurs.
>=20
> Gregg Wonderly
>=20
>=20
>=20


--Apple-Mail=_06BD594C-44BF-47C7-B4FE-DF4D90A2FC19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 26, 2021, at 11:46 PM, Alex Otenko &lt;<a =
href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"auto" =
class=3D"">Well, you made a statement that the hoist of this kind never =
happens in C. It's not true. All I did is found a bizarre example where =
even worse things happen.</div></div></blockquote><div><br =
class=3D""></div><div>You are calling them worse. They are at least =
debuggable. &nbsp;You can use cc -S to stare at the code generated and =
see that the loop disappears.</div><div><br class=3D""></div><div>I said =
this example was not the same because it=E2=80=99s a logic error that =
can be debugged to understand what is happening. &nbsp;I'd take a C/C++ =
program and compile it with -g to have symbol and line number =
information. &nbsp;This allows you to debug this code. The optimizer =
disappears from view and the loop comes back. &nbsp;What I stated about =
C++ specifically is that the loop control expression is not hoisted out =
of the loop and evaluated once, turning the loop into a while(true){} =
condition that never exits and which a debugger can never show you the =
problem because it=E2=80=99s not a logic or data race, it=E2=80=99s an =
optimization that invalidates the way the code is written.</div><div><br =
class=3D""></div><div>If the dev adds logging or other printing =
debugging, the JIT stops the hoist in many cases, and thus it looks like =
something is happening with the =E2=80=9Ccompiler=E2=80=9D breaking the =
code, which it is. &nbsp;But, the user has no idea that =E2=80=98volatile=E2=
=80=99 is required unless they=E2=80=99ve had exposure to the details =
around the whole set of optimizations with fences, cache lines and the =
like. &nbsp; I am contesting that being a precursor to getting working =
code, plain and simple. &nbsp;Why is understanding hardware ever a =
consideration for correct logic to operate? &nbsp;Optimization yes, =
working code, I feel it=E2=80=99s really a detracting =E2=80=98feature=E2=80=
=99 of the JIT.</div><div><br class=3D""></div><div>Gregg</div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><br =
class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Mon, 26 Jul 2021, 23:27 Gregg Wonderly, &lt;<a =
href=3D"mailto:[email protected]" class=3D"">[email protected]</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=3D"">
<br class=3D"">
&gt; On Jul 26, 2021, at 2:06 AM, Alex Otenko via Concurrency-interest =
&lt;<a href=3D"mailto:[email protected]" =
target=3D"_blank" rel=3D"noreferrer" =
class=3D"">[email protected]</a>&gt; wrote:<br =
class=3D"">
&gt; <br class=3D"">
&gt; "Don't write the code like that" is what the others said about =
while(!done), so maybe you can see the point they are making.<br =
class=3D"">
&gt; <br class=3D"">
&gt; As for this example - please take it as an example of code that may =
not behave as written.<br class=3D"">
&gt; <br class=3D"">
&gt; As to why it is written like that - well, it is derived from a more =
elaborate mutually recursive case (with a bug).<br class=3D"">
&gt; <br class=3D"">
&gt; It is perfectly normal to state "zero is even", "x+1 is even, if x =
is odd", and "x+1 is odd, if x is even". This is a recursive definition =
that is derived from a recursive definition of natural numbers. It is =
not complete, but you can't tell if you don't have the compiler that =
will tell you that.<br class=3D"">
&gt; <br class=3D"">
&gt; So you have:<br class=3D"">
&gt; <br class=3D"">
&gt; char odd(int x){return even(x-1);}<br class=3D"">
&gt; char even(int x){return !x || odd(x-1);}<br class=3D"">
&gt; <br class=3D"">
&gt; Inline even into odd, do tail call optimization, and you end up =
with a loop like that (ok, x--, not x++). Both of these steps is what =
modern clang, gcc and llvm do<br class=3D"">
<br class=3D"">
Yes, but this is broken because you can only call even() on evens and =
odd() on odds for it to work.&nbsp; But the tail recursion resolution on =
a -O compilation never loops and just results in a bogus =E2=80=981=E2=80=99=
 return for all cases.&nbsp; With -g, you get infinite recursion that =
crashes with a stack explosion.&nbsp; You can debug this and see =
what=E2=80=99s happening.<br class=3D"">
<br class=3D"">
I=E2=80=99m still completely focused on the fact that the hoist of the =
loop condition makes the code into an infinite loop that you can=E2=80=99t=
 observe, readily, why a value of done=3Dtrue doesn=E2=80=99t cause the =
loop to exit.&nbsp; What you can observe in the value of done should =
cause the loop to exit.&nbsp; It=E2=80=99s subtly different in my =
consideration, but it looks like its a bug because you can=E2=80=99t see =
the code that is executing incorrectly.&nbsp; With this example you =
show, you can put printf in even() and odd(), see the values of x, and =
notice how you end up in odd() with x=3D=3D0 when you call even() with =
an odd value or odd() with an even value and thus the bug occurs.<br =
class=3D"">
<br class=3D"">
Gregg Wonderly<br class=3D"">
<br class=3D"">
<br class=3D"">
<br class=3D"">
</blockquote></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_06BD594C-44BF-47C7-B4FE-DF4D90A2FC19--

--===============2070885152355132238==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29uY3VycmVu
Y3ktaW50ZXJlc3QgbWFpbGluZyBsaXN0CkNvbmN1cnJlbmN5LWludGVyZXN0QGNzLm9zd2Vnby5l
ZHUKaHR0cDovL2NzLm9zd2Vnby5lZHUvbWFpbG1hbi9saXN0aW5mby9jb25jdXJyZW5jeS1pbnRl
cmVzdAo=

--===============2070885152355132238==--