On Tue, 17 Mar 2026 18:09:32 GMT, Raffaello Giulietti <[email protected]> wrote:
>> 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]> > > test/jdk/jdk/classfile/ConstantPoolNaNTest.java line 210: > >> 208: private static <T extends PoolEntry> T findEntry(ClassModel cm, >> Class<T> type) { >> 209: var cp = cm.constantPool(); >> 210: for (int i = 1; i < cp.size(); i++) { > > Suggestion: > > for (int i = 1; i < cp.size(); i += e.width()) { Good suggestion! I've applied this in commit 21abf095904. The for loop with the increment in the loop body is indeed cleaner and more idiomatic. > test/jdk/jdk/classfile/ConstantPoolNaNTest.java line 215: > >> 213: return (T) e; >> 214: } >> 215: i += e.width() - 1; > > Suggestion: This suggestion appears to be incomplete (empty code block). Could you clarify what improvement you had in mind? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30196#discussion_r2951457822 PR Review Comment: https://git.openjdk.org/jdk/pull/30196#discussion_r2951458246
