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

[Przemek Bielicki]

As pointed out by a friendly member of this mailing group (not mentioning
the name for privacy) I'm sharing the ZIP file using GDrive:
https://drive.google.com/file/d/1SMuh71IxtUmZXcE5uvG1ppA0PKQjCOE1/view?usp=sharing

Cheers,
Przemek

On Tue, Dec 19, 2023 at 8:44 AM Przemek Bielicki <pbielicki at gmail.com>
wrote:

> 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/dc3d719a/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/dc3d719a/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/dc3d719a/image-0003.png>