During the review for JDK-8250606 it was noted that the biased-locking section of FastHashCode contained a similar assertion regarding execution at a safepoint:

      // Relaxing assertion for bug 6320749.
      assert(Universe::verify_in_progress() ||
             !SafepointSynchronize::is_at_safepoint(),
             "biases should not be seen by VM thread here");

which gives the impression that it is okay to execute this code block at a safepoint if verify_in_progress(0 is true. But if we examine the next line of code:

  BiasedLocking::revoke(hobj, JavaThread::current());

we find that at a safepoint:
a) JavaThread::current() will assert because the current thread will be the VMThread; and
b) BiasedLocking::revoke itself contains an assertion that it is not invoked at a safepoint.

In practice there is no issue with revoking the bias at a safepoint, we just have to use the right code to do so (as done elsewhere in the same file):

if (SafepointSynchronize::is_at_safepoint()) {
  BiasedLocking::revoke_at_safepoint(hobj);
} else {
  BiasedLocking::revoke(hobj, self);
}