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

Martin Buchholz martinrb at google.com
Mon Jul 7 16:41:22 UTC 2014

I'd like to offer an alternative version of this change. webrev coming soon.

On Sun, Jul 6, 2014 at 8:12 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:

Thanks for suggestion Jeff!

I've tried it, but it doesn't seem to make a difference on my machine. Here are the numbers. I measured the time of a single put in nanoseconds.

----------- | vanila | fix1 | fix2 client | 8292 | 8220 | 8304 server | 8197 | 8198 | 8221 interpreter | 13980 | 14478 | 14152 fix1 - the fix from webrev #3 fix2 - the fix with your suggestion Sincerely yours, Ivan

On 06.07.2014 15:13, Jeff Hain wrote:

>So, I reverted this change to the original code, but added a single >check of the current table size before doing any modifications to the map. >This is to address the issue #4, and this doesn't seem to introduce any >significant penalty. > >Would you please help review the updated webrev: > >http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ <_ _http://cr.openjdk.java.net/%7Eigerasim/6904367/3/webrev/> > >Sincerely yours, > >Ivan It's possible to avoid the capacity test for the general case: put { ...while loop... if (size < threshold) { modCount++; tab[i] = k; tab[i + 1] = value; ++size; } else { putAndResize(k, value, i); } return null; } private void putAndResize(Object k, Object value, int i) { if (size == MAXIMUMCAPACITY - 1) throw new IllegalStateException("Capacity exhausted."); modCount++; Object[] tab = table; tab[i] = k; tab[i + 1] = value; ++size; resize(tab.length); // len == 2 * current capacity. } It seems faster more often than not, but it adds more (and copied) code: not sure it's worth it. -Jeff

More information about the core-libs-dev mailing list