RFR (S) 8049304: race between VM_Exit and _sync_FutileWakeups->inc()
Kim Barrett
kim.barrett at oracle.com
Fri Aug 28 18:27:37 UTC 2015
On Aug 28, 2015, at 11:52 AM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
> This comment:
>
> 570 // Keep a tally of the # of futile wakeups.
> 571 // Note that the counter is not protected by a lock or updated by atomics.
> 572 // That is by design - we trade "lossy" counters which are exposed to
> 573 // races during updates for a lower probe effect.
>
> and this comment:
>
> 732 // Keep a tally of the # of futile wakeups.
> 733 // Note that the counter is not protected by a lock or updated by atomics.
> 734 // That is by design - we trade "lossy" counters which are exposed to
> 735 // races during updates for a lower probe effect.
>
> are not really specific to the monitor subsystem. I think
> the comments are generally true about the perf counters.
Yes, but oddly placed here.
> As we discussed earlier in the thread, generally updating the perf
> counters with syncs or locks will cost and potentially perturb the
> things we are trying to count.
Yes.
> So I think what you're proposing is putting a lock protocol around
> the setting of the flag and then have the non-safepoint-safe uses
> grab that lock while the safepoint-safe uses skip the lock because
> they can rely on the safepoint protocol in the "normal" exit case.
>
> Do I have this right?
Yes. My question is, does the extra overhead matter in these specific cases.
And the locking mechanism might be some clever use of atomics rather than
any sort of “standard" mutex.
And the safepoint-safe uses not only skip the lock, but don’t need to check the
flag at all.
More information about the serviceability-dev
mailing list