RFR: 8320687: sun.jvmstat.monitor.MonitoredHost.getMonitoredHost() throws unexpected exceptions when invoked concurrently [v2]

[Jaikiran Pai]

On Fri, 24 Nov 2023 06:57:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8320687?
>> 
>> As noted in the issue, the `sun.jvmstat.monitor.MonitoredHost.getMonitoredHost()` uses a shared instance of `java.util.ServiceLoader` to load `MonitoredHostService` services. The `ServiceLoader` class javadoc explicitly notes that it isn't thread safe. The issue at hand is caused to due using an instance of `ServiceLoader` concurrently by multiple threads.
>> 
>> The fix proposes to guard the usage of the shared `ServiceLoader` instance through the `monitoredHosts` object monitor. We already use that monitor when dealing with the internal cache which is populated after loading the relevant `MonitoredHostService`(s).
>> 
>> A new jtreg test has been introduced which always reproduces the issue without the source changes and passes with this fix.
>> 
>> tier1, tier2, tier3 and svc_tools tests have been run with this change and all passed.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's review suggestion - rename GetMonitoredHost to ConcurrentGetMonitoredHost
>  - fix code comment

Hello Kevin,

> Do we really need both synchronized(monitoredHosts) blocks -- is the first one needed, now at lines 159 -164 ?
If we don't, then you might not feel the need to create the getCachedMonitoredHost() method which separates the locking from the access you want to protect.

That's a good point. I have taken your input and updated the PR to simplify the synchronized block. The test continues to pass locally (I'll re-run tier testing and svc_tools later today).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16805#issuecomment-1825536913