Coleen raised a possible RFE in her review of:

JDK-8235795 replace monitor list mux{Acquire,Release}(&gListLock) with spin locks

> 1395 // _next_om is used for both per-thread in-use and free lists so
> 1396 // we have to remove 'm' from the in-use list first (as needed).
> 1397 if (from_per_thread_alloc) {
> 1398 // Need to remove 'm' from om_in_use_list.
> ...
> 1467 }
>
>
> None of this code would be needed if om_malloc() doesn't add the monitor to the in-use list until after the header cas succeeds in ObjectSynchronizer::inflate(). You could make sure this code path is tested with a new develop flag StressMonitorInterference.

s/om_malloc()/om_alloc()/

For additional context, the above code is in om_release()...

Thanks for sending a webrev with a prototype of the above changes.
I'm planning to address this as a separate RFE.

It is definitely an interesting RFE that has the potential to
simplify things (without complications)...

I need to research why Dice thought that optimistically adding a
newly allocated ObjectMonitor to the in-use list had benefit...
I also need to look for any unintended side effects...