[F-Req] Java 17/21 support for HarmonyOS NEXT

[joaquimbc]

Describe the bug

Running JRE versions other than 8 on HarmonyOS's Android compatibility layer crashes the game immediately.

The log file and images/videos

latestlog.txt

--------- Starting game with Launcher Debug! Info: Launcher version: amethyst-legacy-20251219-603ff97-feat/import-modpack Info: Architecture: arm64 Info: Device model: HUAWEI QXS-W00 Info: API version: 31 Info: Selected Minecraft version: 1.21.10 Info: Custom Java arguments: "-Xint" Info: Graphics device: HUAWEI Maleoon 910 (OpenGL ES 3) Writing MG configs to /data/user/0/org.angelauramc.amethyst.debug/MobileGlues/config.json MG Config is { "enableANGLE": 0, "enableNoError": 0, "fsr1Setting": 0, "enableExtGL43": 0, "enableExtComputeShader": 0, "angleDepthClearFixMode": 0, "enableExtTimerQuery": 0, "enableExtDirectStateAccess": 0, "multidrawMode": 0, "maxGlslCacheSize": 128 } Added custom env: TMPDIR=/data/user/0/org.angelauramc.amethyst.debug/cache Added custom env: AWTSTUB_WIDTH=1716 Added custom env: FORCE_VSYNC=true Added custom env: POJAV_NATIVEDIR=/data/app/~~PrKXXfoYIkOK_tyMkUnO6w==/org.angelauramc.amethyst.debug-qyxrgiOAri4bH4azDqe3nA==/lib/arm64 Added custom env: MG_DIR_PATH=/data/user/0/org.angelauramc.amethyst.debug/MobileGlues Added custom env: LIBGL_MIPMAP=3 Added custom env: allow_higher_compat_version=true Added custom env: MESA_GLSL_CACHE_DIR=/data/user/0/org.angelauramc.amethyst.debug/cache Added custom env: HOME=/storage/emulated/0/Android/data/org.angelauramc.amethyst.debug/files Added custom env: PATH=/data/user/0/org.angelauramc.amethyst.debug/runtimes/Internal-21/bin:/product/bin:/apex/com.android.runtime/bin:/apex/com.android.art/bin:/system_ext/bin:/system/bin:/system/xbin:/odm/bin:/vendor/bin:/vendor/xbin Added custom env: LIBGL_NOINTOVLHACK=1 Added custom env: force_glsl_extensions_warn=true Added custom env: LIBGL_NORMALIZE=1 Added custom env: POJAV_VSYNC_IN_ZINK=1 Added custom env: LD_LIBRARY_PATH=/data/user/0/org.angelauramc.amethyst.debug/runtimes/Internal-21/lib/jli:/data/user/0/org.angelauramc.amethyst.debug/runtimes/Internal-21/lib:/system/lib64:/vendor/lib64:/vendor/lib64/hw:/data/app/~~PrKXXfoYIkOK_tyMkUnO6w==/org.angelauramc.amethyst.debug-qyxrgiOAri4bH4azDqe3nA==/lib/arm64 Added custom env: LIBGL_NOERROR=1 Added custom env: POJAV_RENDERER=opengles_mobileglues Added custom env: LIBGL_ES=2 Added custom env: VTEST_SOCKET_NAME=/data/user/0/org.angelauramc.amethyst.debug/cache/.virgl_test Added custom env: MESA_LOADER_DRIVER_OVERRIDE=zink Added custom env: POJAVEXEC_EGL=libmobileglues.so Added custom env: JAVA_HOME=/data/user/0/org.angelauramc.amethyst.debug/runtimes/Internal-21 Added custom env: allow_glsl_extension_directive_midshader=true Added custom env: AWTSTUB_HEIGHT=1144 Initializing MobileGlues ... The Open Source License of MobileGlues: GNU LGPL-2.1 License MG_DIR_PATH = /data/user/0/org.angelauramc.amethyst.debug/MobileGlues [MobileGlues] Setting: enableAngle = false [MobileGlues] Setting: ignoreError = 0 [MobileGlues] Setting: enableExtComputeShader = false [MobileGlues] Setting: enableExtGL43 = false [MobileGlues] Setting: enableExtTimerQuery = false [MobileGlues] Setting: enableExtDirectStateAccess = false [MobileGlues] Setting: maxGlslCacheSize = 128 [MobileGlues] Setting: angleDepthClearFixMode = 0 [MobileGlues] Setting: bufferCoherentAsFlush = 1 [MobileGlues] Setting: customGLVersion = 4.0.0 [MobileGlues] Setting: fsr1Setting = 0 EGL initialized successfully OpenGL ES Version: OpenGL ES 3.2 (320) Detected GL_EXT_multi_draw_indirect! [MobileGlues] Setting: multidrawMode = Auto multidrawMode = Auto -> MultidrawIndirect (Auto detected)

A fatal error has been detected by the Java Runtime Environment:

SIGILL (0x4) at pc=0x00000065b2013ba8, pid=39180, tid=39245

JRE version: (21.0.1) (build )
Java VM: OpenJDK 64-Bit Server VM (21.0.1-internal-adhoc.runner.openjdk-21, mixed mode, tiered, g1 gc, linux-aarch64)
Problematic frame:
j java.lang.System.registerNatives()V+0 java.base

Core dump will be written. Default location: core.39180 (may not exist)

An error report file with more information is saved as:
/storage/emulated/0/Android/data/org.angelauramc.amethyst.debug/files/.minecraft/hs_err_pid39180.log
[0.043s][warning][os] Loading hsdis library failed

The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

Steps To Reproduce

1. Start any Minecraft version with JRE>=17
2. Click play
3. Crash

Expected Behavior

Not crash immediately ;p

Platform

- Device model: MatePad Edge
- CPU architecture: AARCH64
- Android version: Android 12
- Amethyst version:

Anything else?

I know this is probably out-of-scope as it's technically not an Android problem... but I would appreciate getting a little insight on it. I've tried debugging it myself but I'm not really familiar with Java, JVM's internals or how it's handled/modified on the launcher

Basically, as the log says it runs into a SIGILL right at the beginning when loading native code. The problem instruction at the crashing address is DCPS1 (C1 D5 BB D4), probably coming from here

void MacroAssembler::stop(const char* msg) {
  // Skip AOT caching C strings in scratch buffer.
  const char* str = (code_section()->scratch_emit()) ? msg : AOTCodeCache::add_C_string(msg);
  BLOCK_COMMENT(str);
  // load msg into r0 so we can access it from the signal handler
  // ExternalAddress enables saving and restoring via the code cache
  lea(c_rarg0, ExternalAddress((address) str));
  dcps1(0xdeae);
}

I'm not sure if stop() is executed because of some failed safety assertion or if it's supposed to self-correct itself, the crash dump has R0 as null so if this didn't crash it wouldn't display a message. Either Kirin chips don't support it or HarmonyOS's emulator doesn't implement it. Older Java versions use BRK instead of DCPS1, which is probably why it won't crash on Java 8

As I said, I don't understand much of Java so I don't know if modifying the JVM to use the old BRK instructions would fix it, or possibly compiling the zero version of hotspot to see if it still fails. I would be willing to fix it myself (if it's something fixable ;p), just a bit unsure on where to start

[alexytomi]

Am gonna need the file at /storage/emulated/0/Android/data/org.angelauramc.amethyst.debug/files/.minecraft/hs_err_pid39180.log

Please attach it as a file.

I know this is probably out-of-scope as it's technically not an Android problem...

Meh, more compatibility more better. Although I don't think I can solve this one since I can't get a hand of any HarmonyOS devices in the near future

[joaquimbc]

hs_err_pid45731.txt.log

This isn't the exact same log, but it's from the same error. I don't think the missing instruction is why it crashed, but I tried to build a JDK with debug or with DCPS1 disabled, but after a few hours I gave up trying to fight the build scripts :')

[alexytomi]

I believe this SIGILL is ignored by android, can you find a way to make HarmonyOS simply ignore it?

[joaquimbc]

But HarmonyOS isn't killing the library, Java is killing itself. The crashing code is the template interpreter compiled at runtime by the interpreter, DCPS1 should definitely not be in there at all, and I don't think the traps to handle the exception are initiated yet. I suspect 2 things:

1. HarmonyOS's emulator wrongly reports CPU information, saying that the real hardware supports while the emulator doesn't. It compiles code assuming that it'll work....and it doesn't. But this still wouldn't really explain the weird instructions or invalid bytes, which leads me to my 2nd theory

2. The emulator is being lazy with cache flushes/updates and the JVM is jumping to code it thinks it's ready but it isn't, or the emulator is losing/corrupting something from the JVM (such as stack and thread handles etc). HarmonyOS also has very strict checks against Write-Execute memory regions, which the interpreter might use

I patched the binary to remove the compile-time assertions that generated DCPS1, but it still ends up generating it anyway, so it's definitely an interpreted stub (and the log says as much too ;p). I can remove the invalid instruction altogether from hotspot, but I'm not sure if that would totally work

// Exception generation jdk/src/hotspot/cpu/aarch/assembler_aarch64.hpp
  void generate_exception(int opc, int op2, int LL, unsigned imm) {
    starti;
    f(0b11010100, 31, 24);
    f(opc, 23, 21), f(imm, 20, 5), f(op2, 4, 2), f(LL, 1, 0);
  }

#define INSN(NAME, opc, op2, LL)                \
  void NAME(unsigned imm) {                     \
    generate_exception(opc, op2, LL, imm);      \
  }

  INSN(svc, 0b000, 0, 0b01);
  INSN(hvc, 0b000, 0, 0b10);
  INSN(smc, 0b000, 0, 0b11);
  INSN(brk, 0b001, 0, 0b00);
  INSN(hlt, 0b010, 0, 0b00);
  INSN(dcps1, 0b101, 0, 0b01); // Here it is!
  INSN(dcps2, 0b101, 0, 0b10);
  INSN(dcps3, 0b101, 0, 0b11);

#undef INSN

But even if I do remove DCPS from the interpreter (just substitute it with BRK's bits), it doesn't changes the fact that for whatever reason it's producing exceptions at runtime, so even if it doesn't causes a SIGILL it'll definitely still crash because of something else. Still, it's worth a shot, if I remove it and it doesn't crashes anymore (either by replacing it with BRK or NOP) then problem solved

I really don't mind debugging this, but I can't really go very far if I can't build modified versions of the bundled JDK 🥹. Compiling a fastdebug build would also be quite useful since they allow me to deactivate/activate more code generation features than the release build. Should I just clone the JDK repo and set up github actions? I don't know how any of it works x.x I tried using the scripts but after many modifications they eventually failed at linking and I just gave up ;-;

[alexytomi]

SIGILL is also reported by android debugger, it is able to handle it and not crash.

Am not familiar with JRE internals, ask @thejudge156

Our JREs are built at https://github.com/AngelAuraMC/angelauramc-openjdk-build. I'd say just actions it.

The debugging code have lots of dependencies on glibc (i.e libsaproc using pr_status_t) which we don't patch around. If you were hoping for that, you're gonna need to do some more work because bionic is poo.

I don't think there exists a JDK build anywhere, not even termux has one.

[alexytomi]

Also are the code snippets you're sending from the HarmonyOS emulator? Like how are you linking the two and two together?

[joaquimbc]

SIGILL is also reported by android debugger, it is able to handle it and not crash.

But the OS isn't the one responsible here, it's the JVM. It's killing itself because it encountered an error that either it couldn't handle (e.g unreachable code, handles still not up etc) or that it thought too severe to continue executing (e.g stack corruption) . If it truly was the OS killing it because of SIGILL, Java wouldn't generate a crashlog or show anything at all as it would be be terminated instantly

I'd say just actions it.
That's what I did haha, I've never used github much and thought I couldn't run my own actions on a fork, but it does xD. I'll write my own patches (probably) tomorrow and see what I can come up with

Also are the code snippets you're sending from the HarmonyOS emulator?

The're code snippets from hotspot, the JRE's JIT native compiler. The HarmonyOS emulator is a complete black box, I don't think I can attach a debugger to it even if I wanted. It's a "3rd party app" that installs apks, but apart from not being able to minimize them and their "android" identification on the icon, there's pretty much no distinction from native apps. The clipboard, network, bluetooth, vpn etc are all shared and there's no user-facing vm layer

Like how are you linking the two and two together?

The reason why I took the JRE's code as an example is because it's the one generating the faulty instructions. One of the first ever methods the JRE executes is the TemplateInterpreterGenerator, basically the JRE builds and compiles its own java bytecode interpreter at runtime. There is no "bytecode interpreter source code" per se, it's all dynamically built during boot. Basically a function that generates assembly to generate another function (the JIT compiler). BUT it's crashing, so the bytecode interpreter never gets built and the JVM just dies since there's literally nothing

The illegal instruction here DCPS1 (a native optional ARM64 instruction) is probably inserted by the template generator because it's supposed to crash. If you disassemble the memory around the crash (it's in the log), you'll see it's a bunch of jumps with the illegal instruction right at the end. After that it's just garbage. So the JVM is checking for something that should aways be true, it isn't and it crashes as a last resort

What I'm not sure about is what is supposed to be on that region, I'm not sure if what's there is valid code that's just failing assertions or if it's garbage generated by something else. The disassembled code assumes that R9 is 0, but R9 is filled with some garbage value (a value that's consistent between runs too). I think the emulator might be using R9, but then I don't think the value would be the constant

The debugging code have lots of dependencies on glibc (i.e libsaproc using pr_status_t) which we don't patch around. If you were hoping for that, you're gonna need to do some more work because bionic is poo.

Do you mean Java's debugger? I don't really need the JDK, I just need a JRE that prints more stuff to the log :P. As I said I dont think I would be able to attach a debugger even if I wanted anyway, so not much I can do with Java's debuggers. I just want more context on the JVM's state right before the crash, dissasembling raw bytes is annoying and way too speculative

*(also please note that I learned about the JVM's internals yesterday, so I'm by no means an expert on it. if i have said anything wrong please do correct me :D)

[joaquimbc]

I should probably report this to OpenJDK itself too since it's a bug on their engine, but I'm not sure if they would accept it since we're running a patched version of it and I'm not exactly running on the expected environment either :P. QEMU suffers from the same-ish problem, so maybe I should check out how they solve it

[alexytomi]

I should probably report this to OpenJDK itself too

I'd say you might have better luck recreating this within termux and asking for help there. They too maintain a fork of java for bionic. This seems to be more up their alley than ours.

The reason why I took the JRE's code as an example is because it's the one generating the faulty instructions. One of the first ever methods the JRE executes is the TemplateInterpreterGenerator, basically the JRE builds and compiles its own java bytecode interpreter at runtime. There is no "bytecode interpreter source code" per se, it's all dynamically built during boot. Basically a function that generates assembly to generate another function (the JIT compiler). BUT it's crashing, so the bytecode interpreter never gets built and the JVM just dies since there's literally nothing

The illegal instruction here DCPS1 (a native optional ARM64 instruction) is probably inserted by the template generator because it's supposed to crash. If you disassemble the memory around the crash (it's in the log), you'll see it's a bunch of jumps with the illegal instruction right at the end. After that it's just garbage. So the JVM is checking for something that should aways be true, it isn't and it crashes as a last resort

What I'm not sure about is what is supposed to be on that region, I'm not sure if what's there is valid code that's just failing assertions or if it's garbage generated by something else. The disassembled code assumes that R9 is 0, but R9 is filled with some garbage value (a value that's consistent between runs too). I think the emulator might be using R9, but then I don't think the value would be the constant

I am seeing a lot of probably's and assumptions on assumptions. I don't think this is right. It's rather suspicious.

But the OS isn't the one responsible here, it's the JVM. It's killing itself because it encountered an error that either it couldn't handle (e.g unreachable code, handles still not up etc) or that it thought too severe to continue executing (e.g stack corruption) . If it truly was the OS killing it because of SIGILL, Java wouldn't generate a crashlog or show anything at all as it would be be terminated instantly

To clarify, android studio finds a SIGILL running libjava.so. I suspect android simply just didn't send it the signal or something about the android emulator. I didn't investigate it further.

*(also please note that I learned about the JVM's internals yesterday, so I'm by no means an expert on it. if i have said anything wrong please do correct me :D)

I think you are already way ahead me

[thejudge156]

Hello @joaquimbc

This appears to be a bug with our patches. In a non-debug state that specific instruction (dcps1) is undefined. Probably leading to the issue you are running into (SIGILL).

I will try to do some digging, but I don't have a harmony device, nor have experience with them.

Thank you.

[thejudge156]

I should probably report this to OpenJDK itself too since it's a bug on their engine, but I'm not sure if they would accept it since we're running a patched version of it and I'm not exactly running on the expected environment either :P. QEMU suffers from the same-ish problem, so maybe I should check out how they solve it

My apologies, I just read this one. Are you using a variant of our patches? Or are you using a completely custom JRE?