I spotted that RISC-V tests are remarkably slow, and profiler shows that `Unsafe.allocateInstance` is very hot, the common stack trace being e.g.:

```
   JavaThread state: _thread_blocked
at jdk.internal.misc.Unsafe.allocateInstance(java.base@20-internal/Native Method)
at java.lang.invoke.DirectMethodHandle.allocateInstance(java.base@20-internal/DirectMethodHandle.java:501)
at java.lang.invoke.DirectMethodHandle$Holder.newInvokeSpecial(java.base@20-internal/DirectMethodHandle$Holder)
at java.lang.invoke.Invokers$Holder.linkToTargetMethod(java.base@20-internal/Invokers$Holder)
at VarHandleBaseTest$Handles.get(VarHandleBaseTest.java:377)
at VarHandleBaseTest$Handles.get(VarHandleBaseTest.java:372)
at VarHandleTestMethodHandleAccessInt.testArray(VarHandleTestMethodHandleAccessInt.java:985)
```

After walking through the VM code, I believe JDK-8130832 (accidentally?) put `_allocateInstance` intrinsic into the block that is conditionalized by `UseUnalignedAccesses`:
 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/abf45dd6ae7c#l5.215

The original block was:
 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/abf45dd6ae7c#l10.298

The intrinsic is currently only implemented in C2. I see no reason for this intrinsic to depend on `UseUnalignedAccesses`: what `LibraryCallKit::inline_unsafe_allocate()` does seems similar to what the regular `Parse::do_new()` does, namely doing the clinit barrier and then delegating into `GraphKit::new_instance`.

Most platforms enable `UseUnalignedAccesses`, so they are not affected by this. Two notable exceptions being ARM32 and RISC-V.

This affects the `java.lang.invoke`-rich paths (e.g. `VarHandles`) that end up calling `Unsafe.allocateInstance`, and rely on intrinsification for reasonable performance.