RFR: 8213942:URLStreamHandler initialization race
sean.coffey at oracle.com
Wed Nov 21 13:04:23 UTC 2018
Thanks to all for the feedback. It makes sense to reduce the scope of
the lock where possible.
I've updated the webrev :
On 20/11/18 20:59, Chris Hegarty wrote:
>> On 20 Nov 2018, at 17:55, Seán Coffey <sean.coffey at oracle.com> wrote:
>> A race condition recently reported by the WLS team. Access to the handlers Hashtable and the factory should be made while holding the streamHandlerLock lock.
>> WLS team also made efforts to create a reproducer. I've modified to jtreg format and reduced it down further for unit testing.
>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8213942/webrev/
> The issue being observed only applies to protocols where there is a
> built-in handler implementation, otherwise I don't see how it can occur.
> The test uses `http`, and clearly there is a built-in `http` handler.
> This is all very racy, partly by design, partly not. I can see that the
> changes in JDK 9 in this area altered the behaviour in such a manner
> that the test which ran successfully on JDK 8, no longer runs
> successfully on JDK 9.
> I see you have some other comments, and I share Pavel's and Alan's
> concern. I've taken a look at the JDK 8 code again , and maybe the
> safest thing here is to try to revert back to a variant that closely
> resembles that.
> One thing to try is to move the `if` statement L1396 outside of the
> synchronized block, and then remove the `else` on L1400. That will allow
> both the handlers cache to be rechecked and the factory ( if there is
> one ) to re-consulted. I believe that should resolve the issue, more
> closely resemble JDK 8, and also address the comments so far ( with
> minimal change ).
>  http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/URL.java
More information about the net-dev