<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 12/19/23 02:44, Przemek Bielicki
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com">
<div dir="ltr">I understand your point. I will work on the
reproducer then. When I'm successful I will just share a link to
github with you - I hope that's OK?</div>
</blockquote>
<br>
yep that's fine,<br>
<br>
<blockquote type="cite" cite="mid:CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>In the meantime, can someone please explain to me the
meaning of those two bytes that switch order?</div>
<div>I'm sending the classes again, this time in a ZIP file as I
guess .class extension may be considered as malware by the
filters (?).</div>
</div>
</blockquote>
<br>
yes I think that .class are not allowed<br>
<br>
<blockquote type="cite" cite="mid:CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Przemek</div>
</div>
</blockquote>
<br>
Thanks,<br>
Vicente<br>
<br>
<blockquote type="cite" cite="mid:CAMvdueCs8VCy60pCBhTtFNPgJ9awo3aiB3td4i7-SkVUGHSSbg@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Dec 18, 2023 at
10:24 PM Vicente Romero <<a href="mailto:vicente.romero@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">vicente.romero@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> I think that having deterministic output is a very
desirable property of a compiler but not a guarantee. If
such non-determinism was provoking a compiler error this
would be a higher priority error. Also as you determined
yourself it is not possible to reproduce the issue with the
test case you sent. We have made efforts in the past to
remove sources of non-determinism in the compiler and I
would say that the ones remaining are harder to remove. We
could dive deeper with a reproductor but without that, it
could be a futile effort,<br>
<br>
Vicente<br>
<br>
<div>On 12/18/23 03:50, Przemek Bielicki wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey Folks,
<div><br>
</div>
<div>
<div>I'm not 100% sure it's the best idea to post it
here but I have no access to the JDK JIRA (yet?) 🙈</div>
<div><br>
</div>
</div>
<div>Last week I had a huge headache because of a bug I
discovered in the Java compiler - Eclipse Temurin
OpenJDK 64-Bit Server VM 17.0.9+9 (mixed mode,
sharing). I'm pretty certain it's a bug because my
expectation is that the compiler MUST produce
deterministic output of the compiled classes - at
least when the JDK version is the same.<br>
</div>
<div><br>
</div>
<div><b>## Expected behavior</b></div>
<div><br>
</div>
<div>Java compiler produces deterministic output i.e
compiled byte code is exactly the same (SHA-wise) and
is independent of the operating system type, version
and other variables.</div>
<div><br>
</div>
<div><b>## Bug description</b></div>
<div><br>
</div>
<div>When compiling 1700+ classes in one of our modules
on different CI agents (with exact same JDK version) I
noticed intermittent SHA differences (of the compiled
classes) that originated from a single class (the
attached GradleExecGraphNodeExecutionInfo.java file.)
It's a sealed interface and it uses records - I have
an impression that using these two in conjunction
plays a role here.</div>
<div><br>
</div>
<div>I also attach the compiled bytecode coming from two
different CI agents.</div>
<div>If you compare the bytecode you will notice this:</div>
<div><img src="cid:part1.GlwjN0OQ.gU0oMbhG@oracle.com" alt="image.png" class="" width="542" height="91"><br>
</div>
<div>The only difference (if the image is not displayed
correctly) is that two same bytes (at the 0x440
position) switch the order depending on where the
class is compiled. I didn't check the meaning of those
bytes - I hope you can help here.</div>
<div><br>
</div>
<div>"javap -c -l -private" shows that the output is
exactly the same (but it isn't).</div>
<div><br>
</div>
<div>The only difference between the CI nodes is the
Linux kernel version (Linux 5.4.0-<b>166</b>-generic
(amd64) vs Linux 5.4.0-<b>167</b>-generic (amd64). I
was able to reproduce this behavior consistently when
I compiled this module on different CI agents with the
same difference in the Linux kernel.<br>
Here's the screen from Develocity showing the diff in
the infrastructure.</div>
<div><img src="cid:part2.Qy1Mw2Lg.x0PxTEf0@oracle.com" alt="image.png" class="" width="542" height="183"><br>
</div>
<div><br>
</div>
<div>I tried to reproduce this problem with the minimal
reproducer (by extracting the sealed interface outside
of the big module) but I failed here. The produced
byte code was the same.</div>
<div><br>
</div>
<div>Please let me know if you need to check sources of
the other classes referenced by this sealed interface.
I'd need to get an approval before sharing them
publicly.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Przemek</div>
<div><br>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>