JDK-8286360 : ARM32: Fix crashes after JDK-8284161 (Virtual Threads)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 19
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch32
  • Submitted: 2022-05-07
  • Updated: 2022-12-23
  • Resolved: 2022-06-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 b26Fixed
Related Reports
Relates :  
JDK-8284161 - Implementation of Virtual Threads (Preview)
Relates :  
JDK-8286365 - Port JEP 425 to ARM32
Description
Starting 2022-05-07, Openjdk head stopped being able to build on 32-bit Raspberry Pi OS

OS: Raspbian GNU/Linux 11 (bullseye) armv 
Host: Raspberry Pi 4 Model B Rev 1.4

---

ERROR: Build failed for targets 'jdk-image test-image-jdk-jtreg-native' in configuration 'linux-arm-server-release' (exit code 2) 
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (templateInterpreterGenerator_arm.cpp:732), pid=22200, tid=22203
#  Error: Unimplemented()
#
# JRE version:  (19.0) (build )
# Java VM: OpenJDK Server VM (19-internal-adhoc.martin.jdk, mixed mode, serial gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0x9c8254]  TemplateInterpreterGenerator::generate_Continuation_doYield_entry()+0x2c
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/martin/ws/jdk/make/hs_err_pid22200.log
   ... (rest of output omitted)

* All command lines available in /home/martin/ws/jdk/build/linux-arm-server-release/make-support/failure-logs.
=== End of repeated output ===
Comments
According to comments in the PR, this fix was tested as follows: Additional testing: - [x] Linux arm32 fastdebug build - [x] Linux arm32 fastdebug, `jdk_loom hotspot_loom` pass - [x] Linux arm32 fastdebug, `jdk_jfr` passes (some timeout failures, because the board I have is very slow) so this fix was verified back on 2022.06.06.
23-12-2022
Changeset: b6c6cc5d Author: Aleksey Shipilev <shade@openjdk.org> Date: 2022-06-07 07:24:20 +0000 URL: https://git.openjdk.java.net/jdk/commit/b6c6cc5d9918bf1727ae13d09f8a3bf677a058a7
07-06-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8634 Date: 2022-05-10 15:51:10 +0000
03-06-2022
JDK-8287496 makes it better, but there are still some C2 problems and asserts. Probably requires a bit of attention.
02-06-2022
I'm very sorry, I did wrong operation.
27-05-2022
I am going to stop working on this issue for a while. Feel free to pick up where I left.
13-05-2022
I had some success with https://github.com/openjdk/jdk/pull/8634 -- ARM32 is able to build, but with disabled C2.
12-05-2022
If you look at the issue for the original Loom integration (JDK-8284161), you would see all the related issues on different platforms.
11-05-2022
fyi, we are seeing this crash on platforms: arm32, riscv64, ppc64 Linux, s390x Linux
11-05-2022
While JDK-8286365 is supposed to implement Loom at ARM32, I think we can get a working VM that does not crash on non-Loom code in this bug. Which would at least allow it to build. The x86_32 change (JDK-8286476) would need to land first, which would work out some of the 32-bit mess.
10-05-2022
Sorry about that.
10-05-2022
There are PRs in progress for risvc and ppc64. Ron mailed aarch32-port-dev about getting arm32 to run again.
10-05-2022
Coleen, this bug is about arm 32-bit (aka aarch32, armv, armv7l), not riscv. The changes in JDK-8286367 are all risc-specific, so it seems very unlikely that it will fix this, although similar changes may be needed for arm Probably all non-amd64, non-aarch64 platforms are currently broken. OK ... Trying ... $ git checkout pull/8595 $ make ... still fails in the same way
10-05-2022
Closing this as a duplicate of the other riscv bug. The other non-Oracle platforms are broken similarly.
10-05-2022
There's a PR for riscv changes to run -version at https://github.com/openjdk/jdk/pull/8595 that fixes this.
10-05-2022
I tried Robbin's suggestion: --- a/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp +++ b/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp @@ -425,8 +425,10 @@ address TemplateInterpreterGenerator::generate_method_entry( case Interpreter::java_lang_math_fmaF : entry_point = generate_math_entry(kind); break; case Interpreter::java_lang_ref_reference_get : entry_point = generate_Reference_get_entry(); break; +#if (defined(X86) || defined(AARCH64)) case Interpreter::java_lang_continuation_doYield : entry_point = generate_Continuation_doYield_entry(); break; +#endif case Interpreter::java_util_zip_CRC32_update : native = true; entry_point = generate_CRC32_update_entry(); break; case Interpreter::java_util_zip_CRC32_updateBytes and ran into new failure mode: * For target jdk__optimize_image_exec: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (templateInterpreterGenerator.cpp:467), pid=28176, tid=28179 # fatal error: unexpected method kind: 27 # # JRE version: (19.0) (build ) # Java VM: OpenJDK Server VM (19-internal-adhoc.martin.jdk, mixed mode, serial gc, linux-arm) # Problematic frame: # V [libjvm.so+0x9c636c] TemplateInterpreterGenerator::generate_all()+0xcfc #
09-05-2022
I think this is a better version: +#if (defined(X86) || defined(AARCH64)) case Interpreter::java_lang_continuation_doYield : entry_point = generate_Continuation_doYield_entry(); break; +#endif This file already have some arch ifdefs.
09-05-2022
I tried patching with: --- a/src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp +++ b/src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp @@ -729,6 +729,7 @@ void TemplateInterpreterGenerator::generate_fixed_frame(bool native_call) { // address TemplateInterpreterGenerator::generate_Continuation_doYield_entry(void) { + if (!Continuations::enabled()) return nullptr; Unimplemented(); return NULL; } but that runs into: * For target jdk__optimize_image_exec: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (stubRoutines.hpp:100), pid=4621, tid=4626 # guarantee(_table_length < _table_max_length) failed: Incorrect UnsafeCopyMemory::_table_max_length # # JRE version: (19.0) (build ) # Java VM: OpenJDK Server VM (19-internal-adhoc.martin.jdk, mixed mode, g1 gc, linux-arm) # Problematic frame: # V [libjvm.so+0x9808dc] UnsafeCopyMemoryMark::UnsafeCopyMemoryMark(StubCodeGenerator*, bool, bool, unsigned char*)+0xc0 I continue to think Raspberry Pi OS 32-bit is an important enough platform to be part of patch acceptance testing
08-05-2022
The initial integration is x64 and aarch64 on the usual operating systems. There are "Unimplemented" stubs for the other architectures. I suspect you should be able to get further if you change TemplateInterpreterGenerator::generate_Continuation_doYield_entry in src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp to add this to the beginning of the function: if (!Continuations::enabled()) return nullptr; I'll move the issue to hotspot/runtime for now.
08-05-2022
Alan will know where this bug belongs
07-05-2022
Unsurprisingly this problem is caused by the big loom integration Author: Alan Bateman <alanb@openjdk.org> Date: Sat May 7 08:06:16 2022 +0000 8284161: Implementation of Virtual Threads (Preview) Alan, thanks for committing on the weekend, making it easy for us Raspberry Pi hobbyists to identify the problem
07-05-2022