RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

Ivan Gerasimov ivan.gerasimov at oracle.com
Tue Jul 8 21:39:18 UTC 2014


Might be worth to add modCount++ before this line:

  487         table = newTable;
  488         return true;


On 09.07.2014 0:07, Martin Buchholz wrote:
> I updated my webrev and it is again "feature-complete".
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/IdentityHashMap-capacity/>
> (old webrev at
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity.0/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/IdentityHashMap-capacity.0/>
> )
>
> This incorporates Peter's idea of making resize return a boolean, 
> keeps the map unchanged if resize throws, moves the check for capacity 
> exceeded into resize, and minimizes bytecode in put().  I'm happy with 
> this (except for degraded behavior near MAX_CAPACITY).
>
>
>
>
> On Tue, Jul 8, 2014 at 8:06 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>     On 07/08/2014 03:00 PM, Ivan Gerasimov wrote:
>
>             I took your latest version of the patch and modified it a
>             little:
>
>             http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/
>             <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/IdentityHashMap/webrev.01/>
>
>
>         But isn't it post-insert-resize vs pre-insert-resize problem
>         Doug mentioned above?
>         I've tested a similar fix and it showed slow down of the put()
>         operation.
>
>     Hi Ivan,
>
>     Might be that it has to do with # of bytecodes in the method and
>     in-lining threshold. I modified it once more, to make put() method
>     as short as possible:
>
>     http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.05/
>     <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/IdentityHashMap/webrev.05/>
>
>     With this, I ran the following JMH benchmark:
>
>     @State(Scope.Thread)
>     public class IHMBench {
>
>         Map<Object, Object> map = new IdentityHashMap<Object, Object>();
>
>         @Benchmark
>         public void putNewObject(Blackhole bh) {
>             Object o = new Object();
>             bh.consume(map.put(o, o));
>             if (map.size() > 100000) {
>                 map = new IdentityHashMap<Object, Object>();
>             }
>         }
>     }
>
>     I get the following results on my i7/Linux using:
>
>     java -Xmx4G -Xms4G -XX:+UseParallelGC -jar benchmarks.jar -f 0 -i
>     10 -wi 8 -gc 1 -t 1
>
>     Original:
>
>     Benchmark                     Mode   Samples        Score  Score
>     error    Units
>     j.t.IHMBench.putNewObject    thrpt        10 13088296.198
>     <tel:13088296.198> 403446.449    ops/s
>
>     Patched:
>
>     Benchmark                     Mode   Samples        Score  Score
>     error    Units
>     j.t.IHMBench.putNewObject    thrpt        10 13180594.537
>     282047.154    ops/s
>
>
>     Can you run your test with webrev.05 and see what you get ?
>
>     Regards, Peter
>
>




More information about the core-libs-dev mailing list