On Wed, 11 Mar 2026 14:32:09 GMT, Shaojin Wen <[email protected]> wrote:
> 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. FYI, this discussion in Double about representation equivalence vs bit-wise equivalence may be useful here: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Double.html#equivalenceRelation HTH ------------- PR Comment: https://git.openjdk.org/jdk/pull/30196#issuecomment-4040690882
