RFR: 8332506: SIGFPE In ObjectSynchronizer::is_async_deflation_needed() [v3]
David Holmes
dholmes at openjdk.org
Tue Jan 7 01:07:39 UTC 2025
On Tue, 7 Jan 2025 00:43:59 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> If `list->max()` is above `old_ceiling` we should use that because the number of actual used monitors, has at one point exceeded the `old_ceiling` value. Why add `monitors_used` to the mix? Any increase in the `list->max()` value will come **after** the increase in `list->count()` aka `monitors_used`. So by adding `monitors_used` to the mix we ensure that `ceiling` can't become zero, even if `old_ceiling` is zero and `list->max()` hasn't been increased yet. Because we [know](https://github.com/openjdk/jdk/blob/502766b759d13edd1ce3f4ebd46fcc8f13ed5d53/src/hotspot/share/runtime/synchronizer.cpp#L1268) that `monitors_used` is not zero.
>>
>> I tried to condense that into a shorter comment, but obviously I failed.
>
> But `monitors_used == list->count()` and `list->count()` by definition must be <= `list->max()`, so including `monitors_used` in the `MAX3` expression is pointless.
>
> EDIT: UGGGHHH! Now I see, because `MonitorList::add` is lock-free we can have count race far ahead of max! Oh that is awful in respect of the current code trying to use both values to decide what to do. :(
In which case may I suggest the following comment:
// Make sure that we use a ceiling value that is not lower than previous, not lower
// than the recorded max used by the system, and not lower than the current number of
// monitors in use (which can race ahead of max). The result is guaranteed > 0.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22815#discussion_r1904789070
More information about the hotspot-runtime-dev
mailing list