> FloatEntryImpl.equals() and DoubleEntryImpl.equals() used == for comparison, > which returns false for NaN == NaN per IEEE 754. This caused two different > FloatEntry/DoubleEntry objects holding NaN to not be considered equal, > violating the equals/hashCode contract (same hashCode but equals returns > false). > > Similarly, SplitConstantPool.findFloatEntry() and findDoubleEntry() used == > to match values, so NaN entries could never be found in the pool, causing > every floatEntry(Float.NaN) or doubleEntry(Double.NaN) call to create a > duplicate entry and bloat the constant pool. > > Fix by using Float.floatToRawIntBits() and Double.doubleToRawLongBits() for > bitwise comparison, which correctly handles NaN and also properly > distinguishes +0.0 from -0.0.
Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - Fix SplitConstantPool lookup hash to match updated entry hashCode The previous commit updated FloatEntryImpl/DoubleEntryImpl to use raw bits for hashCode, but findFloatEntry/findDoubleEntry still used Float.hashCode/Double.hashCode for lookup. This mismatch would cause non-canonical NaN entries to never be found in the map. Co-Authored-By: Claude Opus 4.6 <[email protected]> - Use raw bits for Float/Double constant pool entry hashCode Update hashCode to use floatToRawIntBits/doubleToRawLongBits, consistent with the equals methods, so that different NaN bit patterns hash to different buckets instead of always colliding. Co-Authored-By: Claude Opus 4.6 <[email protected]> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/30196/files - new: https://git.openjdk.org/jdk/pull/30196/files/5ec947ad..3ac3ec6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=30196&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=30196&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/30196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30196/head:pull/30196 PR: https://git.openjdk.org/jdk/pull/30196
