I found the following while trying to reproduce something else.

$ ../build/fastdebug/images/jdk/bin/java -Xshare:off -Xlog:metaspace*=info,gc+heap+coops=debug -XX:CompressedClassSpaceBaseAddress=0x40001000000 -version

Gives:
# Internal Error (/Users/stefank/git/alt2/open/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:5095), pid=13014, tid=10243
# guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment

V [libjvm.dylib+0xcd6c18] MacroAssembler::klass_decode_mode()+0x19c
V [libjvm.dylib+0xcd6eb0] MacroAssembler::decode_klass_not_null(Register, Register)+0x48
V [libjvm.dylib+0xcd4d38] MacroAssembler::load_klass(Register, Register)+0x168
V [libjvm.dylib+0x829af4] InterpreterMacroAssembler::profile_obj_type(Register, Address const&)+0x240
V [libjvm.dylib+0x82ab6c] InterpreterMacroAssembler::profile_return_type(Register, Register, Register)+0x3a8
V [libjvm.dylib+0x10486cc] TemplateInterpreterGenerator::generate_return_entry_for(TosState, int, unsigned long)+0x200

It's unclear to me if this can only happen with the CompressedClassSpaceBaseAddress flag, which is a "development" flag and not avilable in release builds, or if we would hit this failure if the OS ever handed back this address.