openjdk@11 openjdk@17: use llvm to avoid Apple clang 16 failure

[cho-m]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[carlocab]

LGTM. Does their build have any default -O flags (in release mode?) that get set without arg refurbishment?

[Bo98]

Does their build have any default -O flags (in release mode?) that get set without arg refurbishment?

Yeah they use all args. -O3 is the was libjvm should be built with (but is also the thing that crashes). https://github.com/openjdk/jdk/blob/a4cf1918c963cbe0b0eee6db580f0769c0cbdbcc/make/autoconf/flags-cflags.m4#L334-L348. Tweaking that flag is what affects the crash for me.

Slightly cautious doing this given we could just use the Sonoma bottle that works fine on a faster optimisation. Idea in the other PR was to try report this to Apple so that it can be fixed before Sonoma Xcode support ends in (usually) December, so getting a bug report in soon will give us the best chance of that ahead of branch freezes they'll likely have (Swift 6.0.1 is already branched).

If we want to push ahead anyway: can we at least do a benchmark between the two?

[cho-m]

On side note, -fsanitize=undefined does show some UB for openjdk@17 (though may be unrelated as hard to tell if any optimization will trigger problems)

Compiling 4 files for BUILD_JIGSAW_TOOLS
Optimizing the exploded image
ad_aarch64.cpp:12188:6: runtime error: member call on null pointer of type 'RegisterImpl'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ad_aarch64.cpp:12188:6 in
/private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/cpu/aarch64/vmreg_aarch64.inline.hpp:29:28: runtime error: member call on null pointer of type 'RegisterImpl *'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/cpu/aarch64/vmreg_aarch64.inline.hpp:29:28 in
/private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/cpu/aarch64/register_aarch64.hpp:61:9: runtime error: member call on null pointer of type 'const RegisterImpl *'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/cpu/aarch64/register_aarch64.hpp:61:9 in
ad_aarch64.cpp:12189:6: runtime error: member call on null pointer of type 'RegisterImpl'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ad_aarch64.cpp:12189:6 in
ad_aarch64.cpp:12189:18: runtime error: member call on null pointer of type 'VMRegImpl'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ad_aarch64.cpp:12189:18 in
/private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/share/code/vmreg.hpp:100:9: runtime error: member call on null pointer of type 'VMRegImpl *'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/share/code/vmreg.hpp:100:9 in
/private/tmp/openjdkA17-20240917-4348-lho1d6/jdk17u-jdk-17.0.12-ga/src/hotspot/share/code/vmreg.hpp:114:12: runtime error: member call on null pointer of type 'const VMRegImpl *'

---

Can try backporting openjdk/jdk21u@64c0c0e to see if it behaves closer to JDK 21

[cho-m]

Alternatively, we could use llvm by disabling the ptrauth.h usage:

inreplace "src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp" do |s|
  s.sub! "#include <ptrauth.h>", ""
  s.sub! "return ptrauth_strip(ptr, ptrauth_key_asib);", "return ptr;"
end

Related: openjdk/jdk@6fab8a2

[carlocab]

Alternatively, we could use llvm by disabling the ptrauth.h usage:

inreplace "src/hotspot/os_cpu/bsd_aarch64/pauth_bsd_aarch64.inline.hpp" do |s|
  s.sub! "#include <ptrauth.h>", ""
  s.sub! "return ptrauth_strip(ptr, ptrauth_key_asib);", "return ptr;"
end

Related: openjdk/jdk@6fab8a2

Seems reasonable, since I think pointer authentication is only done on arm64e.

If I'm misinformed about this being a no-op on arm64 then this probably needs a bit more discussions.

[cho-m]

Alternatively, we could use llvm by disabling the ptrauth.h usage:

This works for JDK 17 but JDK 11 still fails at same BUILD_JIGSAW_TOOLS step. Could be some fixes that went in between those versions.

[cho-m]

JDK11 seems to be worse off than JDK17+ by triggering UB with misaligned pointers. Avoiding some inlining seems to be a workaround, e.g. from FreeBSD: battleblow/jdk11u@305a68a (interestingly, this was an issue since Clang 13. maybe not hit from shim override of -O3).

[Bo98]

Does the latest JDK trigger any UB (given we're seeing similar miscompiles with that)?

[cho-m]

Does the latest JDK trigger any UB (given we're seeing similar miscompiles with that)?

There is UB. Some have been reported upstream. Snippet of last few using Apple Clang are:

/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64: runtime error: load of misaligned address 0x00011e5e46d9 for type 'u2' (aka 'unsigned short'), which requires 2 byte alignment
0x00011e5e46d9: note: pointer points here
 00 3e 1d  b8 13 00 9a 00 05 03 ac  1c 1d b8 11 00 60 3d a7  ff e2 04 ac ff 01 d9 03  99 12 31 39 12
              ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64 in
/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/share/c1/c1_Instruction.cpp:386:16: runtime error: left shift of negative value -566407518720
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/share/c1/c1_Instruction.cpp:386:16 in
/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/share/ci/ciTypeFlow.hpp:211:62: runtime error: load of value 4294967295, which is not a valid value for type 'Cell'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/share/ci/ciTypeFlow.hpp:211:62 in
/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64: runtime error: load of misaligned address 0x00011e60140d for type 'u2' (aka 'unsigned short'), which requires 2 byte alignment
0x00011e60140d: note: pointer points here
 b8 00 07 b8 00 0d b1  ff 01 69 39 00 00 00 00  08 00 34 00 35 00 00 00  00 00 01 00 37 00 01 00  98
             ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64 in
/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64: runtime error: load of misaligned address 0x00011e601d59 for type 'u2' (aka 'unsigned short'), which requires 2 byte alignment
0x00011e601d59: note: pointer points here
 43 12 11  ff 00 25 00 04 07 00 08  07 02 ed 07 00 56 07 02  ee 00 01 07 00 92 01 fa  00 03 4c 07 00
              ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/src/hotspot/cpu/aarch64/bytes_aarch64.hpp:36:64 in
Exception in thread "main" java.lang.ClassFormatError: StackMapTable format error: bad verification type
	at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
	at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
make[3]: *** [/private/tmp/openjdk-20240918-2656-jahbcl/jdk22u-jdk-22.0.2-ga/build/macosx-aarch64-server-release/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1

Latest LLVM Clang also outputs similar UB.