[~rehn] has an idea to simplify the MonitorDeflationThread by
replacing the MonitorDeflation_lock with a semaphore.

Here's some chat notes:

Robbin Ehn  12:27
We have no critical section, there is no code which the Monitor protect. We are only using the wait/notify.
Since we can miss a notification if we are not waiting while the other thread notifies we need code to handle that.
A semaphore have no critical section, and it keep tracks of the number of notification it have receive, so we never miss a notification.
~Meaning we can remove one variable, we don't need double checking and we can remove the code needed to lock/unlock on both sides.
So a semaphore in this case have only benefits, nothing major, but simpler code. (edited) 

Daniel Daugherty  5 hours ago
Using a monitor is overkill since we don't have a critical section. Got it.
I have to think about the missing notification race.

Robbin Ehn  16:26
I now see we have not yet exposed the semaphores timedwait capability. So we can't do that :disappointed:
Assuming we do expose it:
void MonitorDeflationThread::monitor_deflation_thread_entry(JavaThread* jt, TRAPS) {
  bool was_signaled = false;
  while (true) {
    {
      while (!ObjectSynchronizer::is_async_deflation_needed()) {
        was_signaled = _sema.timedwait_with_safepoint_check(this, GuaranteedSafepointInterval);
      }
    }
    (void)ObjectSynchronizer::deflate_idle_monitors(was_signaled /* forced deflation */);
    was_signaled = false;
  }
}
(edited)

16:26
  void force_deflation() {
    _sema.signal();
  }
16:28
So instead of:
  set_is_async_deflation_requested(true);
  {
    MonitorLocker ml(MonitorDeflation_lock, Mutex::_no_safepoint_check_flag);
    ml.notify_all();
  }
You would just call:
MonitorDeflationThread::force_deflation();
16:30
But as I said it is not possible since we have not expose "timedwait_safepoint_check(...)", only wait_with_safepoint_check(...).