On Wed, 4 Feb 2026 10:03:55 GMT, Paul Hübner <[email protected]> wrote:

> Hi all,
> 
> The main ideas of this patch are to highlight and enforce the invariant we 
> enforce when it comes to value objects' identity hash code. 
> 
> The original JBS issues addresses the following points, which have been 
> addressed to various extents:
> 
> 1. Adding assertions to the CAS-setting of the hash in the markWord. This is 
> vital to enforce the invariant and was added.
> 2. Breaking the loop if the CAS results in a conflict. Putting the identity 
> hash in the markWord is an optimization, so one could break out of the loop 
> whenever. With the assertion, there's a good confidence that CAS will 
> eventually succeed, namely once other threads stop poking at the markWord 
> bits. **If there is demand, I can add a fixed upper bound.**
> 3. SSA-ing the hash variable. Done.
> 4. Possibly introducing a markWord::has_hash to improve legibility. I did not 
> do this as it would yield multiple `obj->mark()` calls in the fast path and 
> the current form is (in my opinion) sufficiently legible. 
> 
> Testing: tiers 1-3 on Linux (x64, AArch64), macOS (x64, AArch64), Windows 
> (x64).

src/hotspot/share/prims/jvm.cpp line 798:

> 796:     //    matter when this is called the same identity hash code is 
> expected.
> 797:     // 2. Oops: the above still applies, but the oops' identity hash 
> code must
> 798:     //    be used as the polymorphic hashCode may change due to 
> mutability.

This is a good description for generating the identity hashcode but seems like 
its in the wrong place... this function doesn't "own" the calculation of the 
hash and the various cases - they belong elsewhere.

The first line `// The generated identity hash is invariantly immutable.` is 
the only part of this that applies in this function.

The reason this comment is odd here is that we don't implement 2 cases here.

-------------

PR Review Comment: 
https://git.openjdk.org/valhalla/pull/2029#discussion_r2795624600

Reply via email to