RFR(s): 8234086: VM operation can be simplified

[Robbin Ehn]

Hi Kim,

On 2019-11-20 21:08, Kim Barrett wrote:
>> On Nov 20, 2019, at 4:38 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>> On 11/19/19 4:55 PM, Kim Barrett wrote:
>>> src/hotspot/share/runtime/synchronizer.cpp
>>> 1006   if (Atomic::load(&ForceMonitorScavenge) == 0 && Atomic::xchg (1, &ForceMonitorScavenge) == 0) {
>>> 1007     VMThread::check_cleanup();
>>> I was going to make a couple nit-pick comments here, but this seems to
>>> be soon to be dead code (only reached when deprecated MonitorBound has
>>> a non-default value).
>>> Not sure it's worth changing this and adding check_cleanup just for
>>> use here though, given this code is going away soon. Are there planned
>>> future uses of check_cleanup?
>>
>> No future plans, no.
>> Are you suggesting doing a synchronous safepoint here instead?
> 
> I think I (and maybe David too) need to better understand what is being done here and why.

Sorry for not making that clear, we have this comment explaining the situation:

       const int mx = MonitorBound;
       if (mx > 0 && (g_om_population-g_om_free_count) > mx) {
         // Not enough ObjectMonitors on the global free list.
         // We can't safely induce a STW safepoint from om_alloc() as our thread
         // state may not be appropriate for such activities and callers may hold
         // naked oops, so instead we defer the action.
         InduceScavenge(self, "om_alloc");
       }

I'm not sure why we only do this if we try to take a monitor from global free 
list. If free list is empty we just allocate instead.

By setting ForceMonitorScavenge and poke the VM thread via 
VMOperationQueue_lock, we still adhere to the comment.

This is not used in "8153224 : Monitor deflation prolong safepoints" patch with 
+AsyncDeflateIdleMonitors. The plan for flag AsyncDeflateIdleMonitors is to 
deprecate it in the release after, so this code is going away.
And thus 'force clean up' can be removed at the same time.

Found some more comments to fix :)

> 
> So go ahead with your original change of using the default destructor.
> 

Ok!

Thanks, Robbin (v3 against RFR mail)