URLStreamHandler.getHostAddress() performance

[Wang Weijun]

> On Nov 25, 2014, at 20:55, Tom Hawtin <tom.hawtin at oracle.com> wrote:
> 
> 
> 
> On 25/11/2014 12:02, Wang Weijun wrote:
>> I am benchmarking security manager and notice this
>> 
>> protected synchronized InetAddress getHostAddress(URL u) {
>> [...]
>> 
>> Is there any reason why the method is synchronized? Why not simply "synchronized (u)"?
> 
> Synchronizing on a public object is usually a bad idea. For instance Thread.join has had some interesting interactions with non-Java library code, and AFAIK that wasn't sprung in an update.
> 
> If the address resolution is not pinned, then unsynchonised access could result in the hostAddress changing, which is bad. However, it seems the major useful effect is to stop a large number of parallel DNS lookups for the same address.

This sounds reasonable. Otherwise I cannot imagine why the calculation needs be taken out of URL class.

> Neither InetAddress nor DNSNameService does not appear to do that itself, though I've not looked deeply into the mechanism.
> 
> So, I would suggest a lock/compare-and-set for just the write to the previously null URL.hostAddress, and locking based on the value of URL.getHost (don't synchronise on String (that'd be a little like synchronising on URL!)!). There's probably several places in the Java library doing something similar with Maps and Futures.

Shall we encapsulate all of these in a new java.net.Host class?

--Max

> 
> Tom