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

Peter Levart peter.levart at gmail.com
Tue Jul 8 21:44:32 UTC 2014


On 07/08/2014 11:39 PM, Ivan Gerasimov wrote:
> Might be worth to add modCount++ before this line:
>
>   487         table = newTable;
>   488         return true;
>
Not quite, I think. The map has just been resized, but it's contents has 
not changed yet logically.

Regards, Peter

> 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