On 02/13/2015 08:47 AM, Peter Levart wrote:
On 02/13/2015 03:54 AM, David Holmes wrote:
Hi Tom,
If you are potentially messing with the (identity) hash of all Java objects in
the 32-bit case then this needs a broader discussion eg on core-libs-dev
(cc'd) as this will impact end-user code the most!
As I understand, this will make identity hashCode have 2^24 instead of 2^25
distinct values on 32 bit architectures, right? This will mostly affect
java.util.IdentityHashMap performance (and any use of objects that don't
override hashCode in other hashCode-based Maps). IHM has a maximum capacity of
2^29 (key, value) slots. Performance will start to degrade sooner - at sizes >
2^24 / 1.5 (~10M) instead of 2^25 / 1.5 (~20M) entries.
In other words, it approximately doubles the probability of a collision
for tables with more than 10 million keys. It's a sure thing that some
applications out there will see measurable slowdowns. So the justification
needed here is whether these slowdowns are more than compensated by the
benefits of adding another age bit. This seems hard to carry out,
but the fallback plan of adding age bit only on 64bit platforms that
don't impact hash bits sounds completely safe.
-Doug
