On Mon, 30 Mar 2026 23:23:32 GMT, Stuart Marks <[email protected]> wrote:
>> While it's true that an entrySet iteration could reduce future maintenance >> costs, it might also affect the performance. The monomorphic path seems like >> it enables better inlining, but the JIT would still have to deal with >> multiple calls to the Iterator and the getKey/getValue calls. Maybe this >> means you'll have to rerun the benchmarks to see if performance is >> equivalent. >> >> I'm still mulling over the impact of including another table-walking + >> next-following nested loops in this code. It might not be that bad after all. > > Another impact of moving to an entrySet iteration is that the keys' hashCodes > need to be recomputed instead of being transferred directly from the source > node. The benchmark uses String keys, which cache their hashCode, so > recomputation might not show up in the benchmark. But other key types might > pay a penalty for the recomputation. @stuart-marks I deliberately chose String to minimize the benchmark overhead, but you are exactly right about both the blind spot and the impact of copying the hashcode vs. recreating it. Good catches. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28243#discussion_r3015646589
