Hello Peter,
I think the comments in compareTo() are now superflucious ("with 0").
Greetings
Bernd
Am Wed, 02 Jul 2014 13:56:39 +0200
schrieb Peter Levart :
> Hi,
>
> I updated the webrev with first two suggestions from Bernd
> (expireTime instead of createTime and cacheNanos + only use
> putI
On 07/03/2014 07:59 PM, Martin Buchholz wrote:
On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad
mailto:claes.redes...@oracle.com>> wrote:
Hi Peter,
perhaps the synchronized(this)-block in
NameServiceAddresses::get() can be replaced with a ReentrantLock?
Applying this on top
On 07/02/2014 05:30 PM, Peter Levart wrote:
Hi Claes,
Thank you for looking into this patch.
On 07/02/2014 04:39 PM, Claes Redestad wrote:
Hi Peter,
perhaps the synchronized(this)-block in NameServiceAddresses::get()
can be replaced with a ReentrantLock? Applying this on top of your
patch,
Hi Claes,
Thank you for looking into this patch.
On 07/02/2014 04:39 PM, Claes Redestad wrote:
Hi Peter,
perhaps the synchronized(this)-block in NameServiceAddresses::get()
can be replaced with a ReentrantLock? Applying this on top of your
patch, I seem to improve scores on your benchmark f
Hi Peter,
perhaps the synchronized(this)-block in NameServiceAddresses::get()
can be replaced with a ReentrantLock? Applying this on top of your
patch, I seem to improve scores on your benchmark for -t 4 by ~33% on my
machine:
--- a/src/share/classes/java/net/InetAddress.javaWed Jul 02
Hi,
I updated the webrev with first two suggestions from Bernd (expireTime
instead of createTime and cacheNanos + only use putIfAbsent instead of
get followed by putIfAbsent):
http://cr.openjdk.java.net/~plevart/jdk9-dev/InetAddress.Cache/webrev.02/
Thanks, Bernd.
The id field in CachedAddr
Hi,
I propose a patch for this issue:
https://bugs.openjdk.java.net/browse/JDK-7186258
The motivation to re-design caching of InetAddress-es was not this issue
though, but a desire to attack synchronization bottlenecks in methods
like URL.equals and URL.hashCode which use host name to IP
