On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Wed, 19 Apr 2023 13:50:49 GMT, Aleksey Shipilev wrote:
> @AlanBateman, @apangin, @ExE-Boss, @liach, @pavelrappo -- you had comments on
> this PR, could you please see if those are still relevant or not addressed?
> If you are good with the current version, can you please formally approve the
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Tue, 18 Apr 2023 19:32:42 GMT, Aleksey Shipilev wrote:
>> `invokespecial` is used to call instance methods in a non‑virtual manner.
>>
>>
>>
>> Using `super.hashCode()` in `java.lang.Enum` produces the bytecode:
On Tue, 18 Apr 2023 19:23:59 GMT, Viktor Klang wrote:
> In such a case, would it not be "better" to base the HC on
> getClass().getName().hashCode() which is specced and stable mixed with the
> ordinal to improve distribution over the 32-bit space?
Maybe, even though it still raises lots of co
On Tue, 18 Apr 2023 17:23:54 GMT, ExE Boss wrote:
>> `super.hashCode()` is a virtual call. `System.identityHashCode` is the
>> static call. I don't understand where `invokespecial` enters the picture
>> here.
>
> `invokespecial` is used to call instance methods in a non‑virtual manner.
>
> ---
On Tue, 18 Apr 2023 09:02:34 GMT, Aleksey Shipilev wrote:
>>> > > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
>>> >
>>> >
>>> > See https://bugs.openjdk.org/browse/JDK-8050217
>>>
>>> Thanks! If there are apps where `Enum::hashCode` is performance sensitive
>>> then run-to-run
On Tue, 18 Apr 2023 08:34:41 GMT, Aleksey Shipilev wrote:
>> Shouldn’t `invokespecial` produce a non‑virtual call as well?
>>
>> And `this`/`super` can never be `null`.
>
> `super.hashCode()` is a virtual call. `System.identityHashCode` is the static
> call. I don't understand where `invokespec
On Mon, 17 Apr 2023 21:12:58 GMT, Jorn Vernee wrote:
> (if anything, using the ordinal would be _more_ stable, since it is only
> affected by the order of the constants, rather than by other code that runs
> before the identity hash code is generated).
Here lies the major original concern -- t
On Tue, 18 Apr 2023 04:49:46 GMT, ExE Boss wrote:
>> Saves the virtual call, makes for a simpler intrinsic path (no need to
>> handle NPE and fold away, for example), since we know the super-class is
>> already `java.lang.Object`. Unless I miss something else here...
>
> Shouldn’t `invokespecia
On Mon, 17 Apr 2023 23:38:31 GMT, John R Rose wrote:
> 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.
On Mon, 17 Apr 2023 13:00:36 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/java/lang/Enum.java line 191:
>>
>>> 189: int hc = hash;
>>> 190: if (hc == 0) {
>>> 191: hc = hash = System.identityHashCode(this);
>>
>> Why not `hc = hash = super.hashCode()`?
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 13:40:02 GMT, Claes Redestad wrote:
> > > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
> >
> >
> > See https://bugs.openjdk.org/browse/JDK-8050217
>
> Thanks! If there are apps where `Enum::hashCode` is performance sensitive
> then run-to-run stability may be
On Mon, 17 Apr 2023 16:44:24 GMT, Aleksey Shipilev wrote:
> I am okay with this new version, thanks. (You need other commenters to
> approve as well.)
While there's already one more reviewer who approved this PR (@cl4es) and
technically it can be already integrated, I'd leave it for a day or t
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie 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
> 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 t
On Mon, 17 Apr 2023 15:41:34 GMT, olivergillespie wrote:
>> Yes, it is a bit strange to see @implNote here as this is a private field
>> that isn't going to show up in the javadoc. The javadoc for non-transient
>> fields in Serializable classes does show up in the Serialized Form page but
>> t
On Mon, 17 Apr 2023 15:55:38 GMT, Aleksey Shipilev wrote:
>> olivergillespie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Switch to non-javadoc comment and remove markup
>
> src/java.base/share/classes/java/lang/Enum.java line 171:
>
On Mon, 17 Apr 2023 15:54:30 GMT, olivergillespie 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
On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie 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
> 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 t
On Mon, 17 Apr 2023 15:30:52 GMT, Alan Bateman wrote:
>> I would change this to be an non-javadoc comment. (Change /** to /*)
>> An there is no need for javadoc \implNote or @link javadoc markup.
>> There is very little value in being able to generate javadoc for --private.
>> (In part because m
On Mon, 17 Apr 2023 15:18:12 GMT, Roger Riggs wrote:
>>> The @implNote is more appropriate for an internal comment. It is not needed
>>> to be in the published javadoc; its only useful to someone viewing the
>>> source code.
>>
>> Is it a comment to me or to the author? If it's the former, the
On Mon, 17 Apr 2023 15:05:46 GMT, Pavel Rappo wrote:
>> The @implNote is more appropriate for an internal comment. It is not needed
>> to be in the published javadoc; its only useful to someone viewing the
>> source code.
>
>> The @implNote is more appropriate for an internal comment. It is not
On Mon, 17 Apr 2023 14:56:13 GMT, Roger Riggs wrote:
> The @implNote is more appropriate for an internal comment. It is not needed
> to be in the published javadoc; its only useful to someone viewing the source
> code.
Is it a comment to me or to the author? If it's the former, then I note, th
On Mon, 17 Apr 2023 14:23:01 GMT, Pavel Rappo wrote:
>> olivergillespie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix two typos
>
> src/java.base/share/classes/java/lang/Enum.java line 177:
>
>> 175: * HotSpot's identity hash
On Mon, 17 Apr 2023 13:49:11 GMT, Aleksey Shipilev wrote:
>> From that impl note it seemed like it was a big deal for hash code to never
>> return 0 for an object. Could you maybe de-emphasize the importance of that
>> HotSpot behavior in the note?
>
> All right, we can change "This allows to t
On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie 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
On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie 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
> 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 t
On Mon, 17 Apr 2023 13:45:05 GMT, Andrei Pangin wrote:
>> olivergillespie has refreshed the contents of this pull request, and
>> previous commits have been removed. Incremental views are not available. The
>> pull request now contains one commit:
>>
>> 8306075: Micro-optimize Enum.hashCode
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie 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
On Mon, 17 Apr 2023 13:45:16 GMT, Pavel Rappo wrote:
>> It would not break the code functionally if that invariant ever breaks: we
>> would "just" call the (intrinsic) method on zero hash code. That `implNote`
>> only shows that it would not happen with current implementation at all.
>
> From t
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie 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
On Mon, 17 Apr 2023 13:08:41 GMT, Aleksey Shipilev wrote:
>> Yes, it is implementation-specific, that is why it says "Hotspot's identity
>> hash code". The relevant code blocks are
>> https://github.com/openjdk/jdk/blob/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b/src/hotspot/share/oops/markWord.hp
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie wrote:
> > Why isn't `Enum::hashCode` simply doing `return ordinal;`?
>
> See https://bugs.openjdk.org/browse/JDK-8050217
Thanks! If there are apps where `Enum::hashCode` is performance sensitive then
run-to-run stability may be a stronger argu
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie 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
On Mon, 17 Apr 2023 13:26:49 GMT, Claes Redestad wrote:
> Why isn't `Enum::hashCode` simply doing `return ordinal;`?
See https://bugs.openjdk.org/browse/JDK-8050217
-
PR Comment: https://git.openjdk.org/jdk/pull/13491#issuecomment-1511350037
On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie 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
On Mon, 17 Apr 2023 13:23:35 GMT, olivergillespie 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
> 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 t
> 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 t
On Mon, 17 Apr 2023 12:58:57 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/java/lang/Enum.java line 175:
>>
>>> 173: *
>>> 174: * @implNote Once initialized, the field value does not change.
>>> 175: * Hotspot's identity hash code generation also never returns zero
>
On Mon, 17 Apr 2023 12:14:55 GMT, Pavel Rappo 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
>> f
On Mon, 17 Apr 2023 10:59:34 GMT, olivergillespie 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
> f
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
52 matches
Mail list logo
