RFR: 8213942:URLStreamHandler initialization race

[Seán Coffey]

On 20/11/2018 19:07, Alan Bateman wrote:
> On 20/11/2018 17:55, Seán Coffey 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.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8213942
>> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8213942/webrev/
> Most URLs are created without specifying a handler so it means 
> creating a URL will go through getURLStreamHandler most of the time. 
> So I think we want to avoid locking on that code path where possible. 
> It's sad that handlers is a Hashtable but I think it makes it worse to 
> have it always synchronize on streamHandlerLock. Reading this code 
> makes me want to replace handlers and replace it with fully concurrent 
> lookups but I realize you might not want to go there for this issue 
> (as I assume you are looking to back-port it). Assuming you don't want 
> a re-write, have you considered always retrying handles.get(protocol) 
> when you acquire the lock?
I'll consider reworking this area Alan. Like you say, if we're 
backporting, then less change could be better.

I tried the re-trying approach but didn't get the desired results. I 
think the factory Object needs to be read/set while holding the lock 
also. Will take a closer look tomorrow.

regards,
Sean.
>
> -Alan