RFR: 8306075: Micro-optimize Enum.hashCode [v6]

[John R Rose]

On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie <duke at 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