URLStreamHandler.getHostAddress() performance

Tom Hawtin tom.hawtin at oracle.com
Tue Nov 25 17:42:52 UTC 2014


On 25/11/2014 14:13, Wang Weijun wrote:

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

I meant the general algorithm for locking based on a value. Though a 
quick look through the JDK source doesn't turn up much.

Looking at it a bit further, it may make sense to push the logic to 
avoid parallel identical DNS lookups down to at least 
InetAddress.getAllByName0. A "value-based" lock around the call to 
getAddressesFromNameService but not getCachedAddresses. This way, large 
numbers of identical, already-cached lookups could have minimal 
interference with each other. The Cache implementation is a bit old 
school, though probably sufficient.

If you have large numbers of simultaneous lookups, I guess they're 
probably all of the same thing. Many class files loaded from the same 
host, for example. So switching from an effectively global lock to a 
lock based on hostname value is unlikely to help performance.

Tom



More information about the security-dev mailing list