RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more) (original) (raw)
Claes Redestad claes.redestad at oracle.com
Thu Jul 3 18:13:59 UTC 2014
- Previous message: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)
- Next message: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 07/03/2014 07:59 PM, Martin Buchholz wrote:
On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> 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 for -t 4 by ~33% on my machine: Once upon a time ReentrantLock had some performance advantage over builtin synchronized; but today best practice is to prefer ReentrantLock only for the software engineering advantages like more flexibility or clarity.
This was my feeling as well, but when I saw the remaining synchronized block in Peter's patch I got curious to see if that notion still held up. Sorry for being sloppy with the benchmarking and throwing a red herring into the mix, though.
/Claes
- Previous message: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)
- Next message: RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]