On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <d...@openjdk.org> wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first >> use. I've seen an application where Enum.hashCode is a hot path, and this is >> fairly simple speedup. The memory overhead is low; in enums with no extra >> fields there is already a 4-byte space due to alignment so this new field >> can slot in 'for free'. In other cases, the singleton nature of enum values >> means that the number of total instances is typically very low, so a small >> per-instance overhead is not a concern. >> >> Please see more discussion/explanation in the [original enhancement >> request](https://bugs.openjdk.org/browse/JDK-8306075). [Benchmark results >> and generated code analysis moved to comment] >> >> Thanks @shipilev for help with the implementation and interpreting the >> generated code. > > olivergillespie has updated the pull request incrementally with one > additional commit since the last revision: > > Shuffle docs I don’t have a strong objection to this, but I would like to say for the record that it is likely we will want to reconsider enums in a larger sense after Valhalla starts to ship. Specifically, if an enum is represented as a value object, it should be represented as a single ordinal value after flattening. This means both the old name and the new hash fields should not be present in a value-class version of an enum; they should be computed by using the ordinal as a key into some other table or algorithm. In the long-running discussion about enum hash codes I added a comment here FTR: https://bugs.openjdk.org/browse/JDK-8050217?focusedCommentId=14574367&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14574367 This sketches in more detail what I mean by deriving the hash from the ordinal and the class. These suggestions may be of interest to people looking at this RFE. But I am not suggesting a change to this RFE. I do have one comment: Since identity hash codes are typically reasonably well-conditioned, it is perfectly reasonable to recondition an occasional 0 by replacing it with 1, in order to store it in a stable variable for later reuse. (Those hash codes are not so well-conditioned that that one tweak would cause quality tests to go from green to red; a test that could detect the tweak would already be red.) But it’s also harmless to leave it as zero; it just means you will occasionally see a failure of constant folding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1512238902
