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

[Vicente Romero]

On 12/19/23 02:44, Przemek Bielicki 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?

yep that's fine,

>
> 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 (?).

yes I think that .class are not allowed

>
> Przemek

Thanks,
Vicente

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