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