Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: java8 up to 6x slower than java7
Date: Mon, 03 Mar 2014 19:53:27 +0100
Organization: albasani.net
Lines: 77
Message-ID: <lf2j36$cu4$1@news.albasani.net>
References: <29a51a94-8f9a-41b1-980f-e8c13e2d11a2@googlegroups.com> <ldnitt$mtv$1@news.albasani.net> <ldnkf1$pp0$1@news.albasani.net> <bmbo69F4b27U1@mid.individual.net> <ldqf11$adv$1@news.albasani.net> <ldqf9a$adv$2@news.albasani.net> <bmbu5tF5ju8U1@mid.individual.net> <ldr3ep$m2v$1@news.albasani.net> <ldr3vk$n4h$1@news.albasani.net> <bmf0noFpsoqU1@mid.individual.net> <MPG.2d7daa55f1e6c2a8b@202.177.16.121> <lf1mvk$iho$1@news.albasani.net> <lke298guvu4z.12emsy2hy4q19$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net K7Bm4jKMLlCvqRGW01xpwra0ifbU+K+vC0c32DjNi2CKoNbgA4WSFKI5nHW3GWB97GpG5ZvBROOgDAbxbx7Quw==
NNTP-Posting-Date: Mon, 3 Mar 2014 18:53:27 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="ZWuFdTmRGhunnbZucSQnJS2uRvMOyy5NYRkx+POoas1i1nuPmSCiEA8+u49SxUuzvsXfXX/IGIbS1Qf6kiZEB14dDNZf9IWNcoY3tLrq7z++3XkBfXgmBIcarBbcJU5X"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
In-Reply-To: <lke298guvu4z.12emsy2hy4q19$.dlg@40tude.net>
Cancel-Lock: sha1:Ni3TnzIV7qzZJSWykX2Gq2daTQ4=
Xref: csiph.com comp.lang.java.programmer:27673

Hi,

It seems to me that the ConcurrentHashMap of JDK 8
adopts the tree structure for lage bins already
found in the HashMap of JDK 8. Namely I find:

    ConcurrentHashMap JDK 5:
        No method treeifyBin in source code found.
        (Related to this thread, i.e. is JDK 8 slower?)
        No method computeIfAbsent in source code found.
        (Not directly related, but also interesting)

    ConcurrentHashMap JDK 8:
        A method treeifyBin in source code found.
        (Related to this thread, i.e. is JDK 8 slower?)
        A method computeIfAbsent in source code found.
        (Not directly related, but also interesting,
         see also: 
http://stackoverflow.com/questions/19278443/how-do-i-use-the-new-computeifabsent-function)

Since ConcurrentHashMap uses more effectively inner
locks, I will destroy all this efficiency when I
use an outer lock.

This is my concern when I would use the concurrent
hash map as follows:

     synchronized(map) {
         /* do more than one operation on map,
            atomically */
     }

This concern also holds if I use as an extra lock
for example:

     public final lock = new Object();

     synchronized(lock) {
         /* do more than one operation on map,
            atomically */
     }

The only benefit respectively drawback of the
extra lock is that more memory is used.

But nevertheless the pattern of an extra lock
is often seen for various reasons.

Bye

Joerg Meier schrieb:
> On Mon, 03 Mar 2014 11:53:41 +0100, Jan Burse wrote:
>
>> Me myself is anyway a hopeless case. I just discovered
>> ConcurrentHashMap in JDK 8. Very interesting, it doesn't
>> use a lock on the outside, but I counted 9 times a
>> synchronized statement inside the code.
>
> From
> <http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ConcurrentHashMap.html>
>
> Since:
>      1.5
>
> Not exactly new ;)
>
> As for your problem, I didn't quite understand your problem description,
> but just in case you aren't aware, you don't have to synchronize on the
> object you deal with in the block - you can synchronize on anything you
> want, and many people use a helper field like
>
> private final Object $LOCK = new Object();
>
> Liebe Gruesse,
> 		Joerg
>