-
Bug
-
Resolution: Fixed
-
P2
-
10
-
Note how crc32 isn't present on this particular machine's /proc/cpuinfo:
Processor : AArch64 Processor rev 0 (aarch64) processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 processor : 6 processor : 7 Features : fp asimd evtstrm CPU implementer : 0x50 CPU architecture: AArch64 CPU variant : 0x0 CPU part : 0x000 CPU revision : 0 Hardware : APM X-Gene Mustang board
Note how crc32 isn't present on this particular machine's /proc/cpuinfo: Processor : AArch64 Processor rev 0 (aarch64) processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 processor : 6 processor : 7 Features : fp asimd evtstrm CPU implementer : 0x50 CPU architecture: AArch64 CPU variant : 0x0 CPU part : 0x000 CPU revision : 0 Hardware : APM X-Gene Mustang board
There was a simple bug that prevents the JVM from running on X-Gene 1 machines, and therefore doesn't successfully complete the build.
The CRC32C intrinsic is intended to only work with the CRC32C intructions, unlike with CRC32 where there is also a NEON and integer implementation.
The UseCRC32Intrinsics option is enabled by default. The method:
TemplateInterpreterGenerator::generate_CRC32C_updateBytes_entry
in hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
is being enabled because of the UseCRC32Intrinsics option and not the UseCRC32CIntrinsics option, and so there was an attempt to generate a relative branch to the address in StubRoutines::_updateBytesCRC32C .
That address is NULL as the stub is never generated as UseCRC32CIntrinsics isn't enabled. If it was enabled, it should produce a SIGILL.
The error produced during the build is:
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (assembler_aarch64.hpp:251), pid=6517, tid=6518
# guarantee(chk == -1 || chk == 0) failed: Field too big for insn
The associated backtrace:
V [libjvm.so+0x2c5784] Assembler::b(unsigned char*)+0xb8
V [libjvm.so+0x102ba7c] TemplateInterpreterGenerator::generate_CRC32C_updateBytes_entry(AbstractInterpreter::MethodKind)+0x23c
V [libjvm.so+0x1026b80] TemplateInterpreterGenerator::generate_method_entry(AbstractInterpreter::MethodKind)+0xf0
V [libjvm.so+0x1025ac0] TemplateInterpreterGenerator::generate_all()+0x1580
V [libjvm.so+0x102451c] TemplateInterpreterGenerator::TemplateInterpreterGenerator(StubQueue*)+0x54
V [libjvm.so+0x1022ad4] TemplateInterpreter::initialize()+0x120
V [libjvm.so+0xa9cc1c] interpreter_init()+0x20
V [libjvm.so+0xa7aa98] init_globals()+0x68
The CRC32C intrinsic is intended to only work with the CRC32C intructions, unlike with CRC32 where there is also a NEON and integer implementation.
The UseCRC32Intrinsics option is enabled by default. The method:
TemplateInterpreterGenerator::generate_CRC32C_updateBytes_entry
in hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
is being enabled because of the UseCRC32Intrinsics option and not the UseCRC32CIntrinsics option, and so there was an attempt to generate a relative branch to the address in StubRoutines::_updateBytesCRC32C .
That address is NULL as the stub is never generated as UseCRC32CIntrinsics isn't enabled. If it was enabled, it should produce a SIGILL.
The error produced during the build is:
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (assembler_aarch64.hpp:251), pid=6517, tid=6518
# guarantee(chk == -1 || chk == 0) failed: Field too big for insn
The associated backtrace:
V [libjvm.so+0x2c5784] Assembler::b(unsigned char*)+0xb8
V [libjvm.so+0x102ba7c] TemplateInterpreterGenerator::generate_CRC32C_updateBytes_entry(AbstractInterpreter::MethodKind)+0x23c
V [libjvm.so+0x1026b80] TemplateInterpreterGenerator::generate_method_entry(AbstractInterpreter::MethodKind)+0xf0
V [libjvm.so+0x1025ac0] TemplateInterpreterGenerator::generate_all()+0x1580
V [libjvm.so+0x102451c] TemplateInterpreterGenerator::TemplateInterpreterGenerator(StubQueue*)+0x54
V [libjvm.so+0x1022ad4] TemplateInterpreter::initialize()+0x120
V [libjvm.so+0xa9cc1c] interpreter_init()+0x20
V [libjvm.so+0xa7aa98] init_globals()+0x68
- relates to
-
JDK-8189745 AARCH64: Use CRC32C intrinsic code in interpreter and C1
-
- Resolved
-