URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Wang Weijun
I am benchmarking security manager and notice this protected synchronized InetAddress getHostAddress(URL u) { if (u.hostAddress != null) return u.hostAddress; String host = u.getHost(); if (host == null || host.equals("")) { return null; } else { try {

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Tom Hawtin
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 b

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Wang Weijun
> On Nov 25, 2014, at 20:25, Pavel Rappo wrote: > > Hi Max, > > I don't see any particular reason for this. Maybe it's just a "precaution". > It seems to me it's the only field > of the URL class set directly (without setter) from an outside. > > Does it hurt performance a lot? In what cases?

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Mark Sheppard
I think this raises a more fundamental question, as to why the URL hashCode() and equals() methods delegates to URLStreamHandler in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within. If you call equals() and hasCode()

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Wang Weijun
> On Nov 25, 2014, at 20:55, Tom Hawtin 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 sim

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread 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 do

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Tom Hawtin
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

Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters

2014-11-25 Thread Otávio Gonçalves de Santana
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 WEBREV: http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ -- Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Pavel Rappo
Hi Max, I don't see any particular reason for this. Maybe it's just a "precaution". It seems to me it's the only field of the URL class set directly (without setter) from an outside. Does it hurt performance a lot? In what cases? -Pavel > On 25 Nov 2014, at 12:02, Wang Weijun wrote: > > I am

Re: URLStreamHandler.getHostAddress() performance

2014-11-25 Thread Pavel Rappo
Max, this change dates back to 99/06/11. And there's not much info left on it. I suggest changing and running the full test suit. P.S. I assume the whole synchronization burden in the URL comes from lazy initialization of hostAddress and lazy computation of the hashCode (...and access to shared