URLStreamHandler.getHostAddress() performance

[Bernd Eckenfels]

Hello,

well first of all, why is it doing a lookup at all? It the URL was
specified with a hostname I guess that one is used. If the InetAddress
object in the URL had no hostname, you probably do not want to reverse
resolve one for Security Manager purpose.

However, back to the synchronized: I dont think this is needed,
InetAddress does synchronisation itself
(InetAddress.getAddressFromNameService() is used inside
synchronized(cacheLock)).

Gruss
Bernd


 Am Tue, 25 Nov 2014 22:13:10 +0800
schrieb Wang Weijun <weijun.wang at oracle.com>:

> 
> > 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
>