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

[Vicente Romero]

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.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.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/20231218/2098a169/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/20231218/2098a169/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/20231218/2098a169/image-0003.png>