JDK-8325587 made the contended lock acquisition as the CAS loop with backoffs. We are currently spinning for 0xFFF (4K) times before blocking. Even on non-overloaded systems, if we assume the spinwait cost is ~10ns to call the stub, we would spend about 40us before blocking. This increases TTSP.

On loaded systems, we would need to wait for threads to roll over the spinwait before they can block. For the overload factor of 100 (e.g. 6400 thread on 64-core machine), this would mean 4ms of additional TTSP.

We can probably mitigate this by spinning for shorter duration.

Sample test:

```
public class Alloc {
        static final int THREADS = 1024;
        static final Object[] sinks = new Object[64*THREADS];
        static volatile boolean start;
        static volatile boolean stop;

        public static void main(String... args) throws Throwable {
                for (int t = 0; t < THREADS; t++) {
                        int ft = t;
                        new Thread(() -> work(ft * 64)).start();
                }

                start = true;
                Thread.sleep(10_000);
                stop = true;
        }

        public static void work(int idx) {
                while (!start) { Thread.onSpinWait(); }
                while (!stop) {
                        sinks[idx] = new byte[128];
                }
        }
}
```

Run it like this and observe TTSP times:

```
java -Xms256m -Xmx256m -XX:+UseShenandoahGC -XX:-UseTLAB -Xlog:gc -Xlog:safepoint Alloc.java
```

Things to consider:
 1) Do we need to check for `SafepointSynchronize::is_synchronizing()` to exit spinning early when safepoint is pending?
 2) Does `ThreadBlockInVM` do suspension correctly?
 3) Do we need to unpark from sleep faster (somehow?) when safepoint is over? That may involve switching to mutex of some sort.

Note from Roman:
I have a feeling that #1 and #2 can both be achieved by simply adding 'true' to the ThreadBlockInVM constructor invocation.