[macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash

I have found an issue in hotspot for macos_aarch64
it was sitting there since jep-391 integration, but only got discovered in macos 11.4beta

so, InterpreterRuntime::throw_pending_exception ends this way
libjvm.dylib`InterpreterRuntime::throw_pending_exception:
-> 0x105c67ecc <+268>: b 0x105fc099c ; os::current_thread_enable_wx(WXMode)

it's destructor of ThreadWXEnable __wx(WXWrite, current) from JRT_ENTRY block

os::current_thread_enable_wx ends up calling pthread_jit_write_protect_np in same manner, but since 11.4b, pthread_jit_write_protect_np does pacibsp as it's very first instruction, making LR register poisoned with PAC signature:

libsystem_pthread.dylib`pthread_jit_write_protect_np:
-> 0x1888c84ec <+0>: pacibsp
  0x1888c84f0 <+4>: stp x29, x30, [sp, #-0x10]!
Lr before pacibsp:
   lr = 0x00000001279c1a5c
Lr after pacibsp
   lr = 0x74588001279c1a5c

after some time, this lr is passed to
address SharedRuntime::raw_exception_handler_for_return_address
as return_address value
(via forward exception stub)
 as a result, raw_exception_handler_for_return_address processes PAC-poisoined pointer and crashes at should_not_reach_here

Dumping bad pointer with additional logging at the end of raw_exception_handler_for_return_address
reveals it's the same pointer:

No exception handler found for exception at 0x74588001279c1a5c - potential problems:

Happens only on release build, fastdebug build has some additional code which prevents that.

While I believe the pacibsp in arm64 ( not arm64e) is a bug of macos beta, it revealed another issue in jvm.
Update: not a macos bug, intended behaviour