8373202: [lworld] ObjectReference.equals should follow == semantics for value objects

[alexmenkov]

Updated implementation of ObjectReference.equals and ObjectReference.hashCode to comply the spec for value objects.
Added the test for value object ctor debugging, the test verifies the behaviour is expected.
There is an issue with instance filter, it till be fixed separately (it's not yet clear how it would be better to fix it)

testing: tier1..4, hs-tier5-svc

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

• JDK-8373202: [lworld] ObjectReference.equals should follow == semantics for value objects (Bug - P3)

Reviewers

• Serguei Spitsyn (@sspitsyn - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/1834/head:pull/1834
$ git checkout pull/1834

Update a local copy of the PR:
$ git checkout pull/1834
$ git pull https://git.openjdk.org/valhalla.git pull/1834/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1834

View PR using the GUI difftool:
$ git pr show -t 1834

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1834.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back amenkov! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@alexmenkov This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8373202: [lworld] ObjectReference.equals should follow == semantics for value objects

Reviewed-by: sspitsyn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 269 new commits pushed to the lworld branch:

• 43b6a73: 8376145: [lworld] Enable SubstitutabilityTest.java with AOTJDK
• 258bd58: 8376128: [lworld] ProblemList valhalla/valuetypes/SubstitutabilityTest.java with AOTCache again
• ccb0ca8: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the same for identical value objects
• ... and 266 more: https://git.openjdk.org/valhalla/compare/13abe7d1172a3e6a31a76756be8810b674f35ad4...lworld

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

[openjdk]

⚠️ @alexmenkov This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[mlbridge]

Webrevs

• 04: Full - Incremental (583f9e33)
• 03: Full - Incremental (55ba1462)
• 02: Full - Incremental (34c9c2bd)
• 01: Full - Incremental (e74a4cff)
• 00: Full (f82f5be4)

[plummercj]

What happens if not running in preview mode? Value classes are not supported in that case, but as implemented this API will say they are supported, leading to isValueClass() looking at modifiers in a way that is not compatible when value classes are not supported.

JDI didn't really run into this type of problem with virtual thread support. It did modify a couple of new public APIs with:

@PreviewFeature(feature = PreviewFeature.Feature.VIRTUAL_THREADS)

However, I don't see how that helps us here. It seems we need to query the debug agent to find out if value classes are supported. There's no good way to do that. Is there any way for JDI to somewhat detect that value class support is supported (preview mode is enabled).

[sspitsyn]

What happens if not running in preview mode? Value classes are not supported in that case, but as implemented this API will say they are supported, leading to isValueClass() looking at modifiers in a way that is not compatible when value classes are not supported.

It should work correctly. The IDENTITY modifier bit is not used for other purposes in JDK 27 (Alex, please, fix me if it is wrong). So, the check for version >= 27 is needed. If preview is not enabled in target VM, so it does not support value classes then the IDENTITY modifier bit will be always set which results in isValueClass() to always return false.

[plummercj]

So in JDK 27, with or without enable preview, the IDENTITY modifier bit is accurate and can be looked at, but in previous JDK versions it might be used for something else?

[alexmenkov]

So in JDK 27, with or without enable preview, the IDENTITY modifier bit is accurate and can be looked at, but in previous JDK versions it might be used for something else?

Correct

[sspitsyn]

testing: tier1..4, hs-tier5-svc

I'd suggest to run mach5 full tier-5 and tier-6 as well.

[alexmenkov]

testing: tier1..4, hs-tier5-svc

I'd suggest to run mach5 full tier-5 and tier-6 as well.

in progress

[sspitsyn]

Thank you for updates! It looks good to me.