`ClassIndex` does not handle duplicate identity hash codes
TheMode opened this issue · 2 comments
I may be wrong, but ClassIndex does not seem to handle System.identityHashCode returning the same for two distinct classes, as collision detection is only implemented based on the even smaller hashBits field. Which is an unlikely scenario, but not impossible.
Good question.
SA: Yes, ClassIndex detects the unlikely collision and will exit with a clear error without starting to mess up with the user application data.
LA: you went straight on to the core of the library where (one of) the magic happens. Java doesn't provide a safe unique id for a Class type - as far as I know, and I'm open to discussion and very happy if someone will come up with a different approach.
That means you should always rely on the equals() check to prevent collisions. Here is a trade-off, implement lightning-fast (around 1ns) checking to detect a class type with a 99.999999999% success rate or have the worst performance just to avoid a very unlikely collision that could occur much less frequently than a common OutOfMemory error.
I will not close this issue just yet to leave the discussion open for a while.
Updated implementation:
- ClassIndex switches from the super-fast sparse memory data structure to a concurrent map when the first hashCode collision occurs (if any)
- added new benchmarks for the fallback map
- added a concurrent unit test to validate the implementation