[Bug] javac gives non-deterministic output (for sealed interface with records)

[Przemek Bielicki]

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?

In the meantime, can someone please explain to me the meaning of those two
bytes that switch order?
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 (?).

Przemek

On Mon, Dec 18, 2023 at 10:24 PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> 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,
>
> Vicente
>
> On 12/18/23 03:50, Przemek Bielicki wrote:
>
> Hey Folks,
>
> I'm not 100% sure it's the best idea to post it here but I have no access
> to the JDK JIRA (yet?) 🙈
>
> 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.
>
> *## Expected behavior*
>
> 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.
>
> *## Bug description*
>
> 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.
>
> I also attach the compiled bytecode coming from two different CI agents.
> If you compare the bytecode you will notice this:
> [image: image.png]
> 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.
>
> "javap -c -l -private" shows that the output is exactly the same (but it
> isn't).
>
> The only difference between the CI nodes is the Linux kernel version
> (Linux 5.4.0-*166*-generic (amd64) vs Linux 5.4.0-*167*-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.
> Here's the screen from Develocity showing the diff in the infrastructure.
> [image: image.png]
>
> 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.
>
> 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.
>
> Cheers,
> Przemek
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9238 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/image-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 165378 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231219/be634d65/image-0003.png>