<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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 class="moz-cite-prefix">On 12/18/23 03:50, Przemek Bielicki
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAMvdueDpt2rbvaF6JhSP_zbONDFa1kjUCTcPOFosyNZR61yMSQ@mail.gmail.com">
<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.ecBjfVD9.tWObdhA0@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.YpRQtovg.VAconaNA@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>
</body>
</html>