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

alexmenkov · 2025-12-18T20:00:45Z

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)

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

This reverts commit 1d883c2.

bridgekeeper · 2025-12-18T20:02:47Z

👋 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 · 2025-12-18T20:09:50Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c

…_debug

openjdk · 2026-01-10T00:59:34Z

⚠️ @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 · 2026-01-12T21:55:42Z

Webrevs

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c

src/java.se/share/data/jdwp/jdwp.spec

test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java

plummercj · 2026-01-14T04:16:31Z

src/java.se/share/data/jdwp/jdwp.spec

            (Error VM_DEAD)
        )
    )
+    (Command IsSameObject=11


Are you going to add "preview API" warnings to these two APIs?

I'm not sure it makes much sense.
They are quite generic, I think about adding them to mainline in jdk 27 (but don't use by ObjectReferenceImpl.equals/hashCode)

They might be generic, but they serve no useful purpose outside of valhalla support.

src/java.se/share/data/jdwp/jdwp.spec

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java

plummercj · 2026-01-14T04:34:02Z

src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java

    }

+    // Inline type is a concrete value class.
+    boolean isInlined() {


Why is this called isInlined()? Shouldn't it be isValueClass()? Do we want to expose it to users through ReferenceType? Should we also consider exposing a new isIdentity() API?

Why is this called isInlined()? Shouldn't it be isValueClass()?

I had the same question. The isInlined() matches the obsolete approach. The isValueClass() looks better.

Do we want to expose it to users through ReferenceType?

If the JDI implementation needed it then there are some chances debuggers may need it as well. We have some time to decide. Preview allows to change the API specs in the future. I have a minor preference to expose it now. It is pretty simple and clear.

Should we also consider exposing a new isIdentity() API?

It would be consistent with other modifier bits.

isInlined name (and its implementation) is consistent with hotspot code.
This API if required by ObjectReferenceImpl to determine if the reference is a value object (so the class cannot be abstract or interface).
To me IsIdentity (I think isValue is better) should be in ClassType, I'm updating ClassTypeImpl, it can be added to ClassType interface later if debuggers really need it).

isInlined name (and its implementation) is consistent with hotspot code.

But in the case of JDI we are talking about a potentially external API.

To me IsIdentity (I think isValue is better) should be in ClassType

We need to be careful of the use of "value" in JDI since we already have com.sun.jdi.Value, which peculates into all sorts of APIs like ObjectReference.getValue(Field) and BooleanValue. It doesn't help any that we also have Value.type().

ClassType laready has isEnum(), so isValue looks more consistent.
Maybe isValueClass? Anyway it's not too important now (while it's internal API)

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c

test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

plummercj · 2026-01-16T03:19:45Z

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

-            return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode;
-        } catch (JDWPException exc) {
-            throw exc.toJDIException();
+        if (isValueObject() && vm.canUseIsSameObject()) {


I don't see how this logic can be correct for value objects if vm.canUseIsSameObject() returns false. We still have a value object in that case. Is using Long.hashCode(ref()) the right thing to do? Same thing applies to equals() above. I think if a JVM supports value objects then the debug agent has to support IsSameObject and HashCode. The version check should really only be in regard to whether or not value objects are supported in general by the JVM, because if they are they have to be supported by the debug agent.

We should execute jdwp command only when it's available (vm.canUseIsSameObject returns true) and the object is value object.
Note that isValueObject() may not work for old releases, so we need to check both conditions here or move version check to ClassTypeImpl.isValueClass

If the JVM supports value objects, the debug agent has to support IsSameObject and ObjectHashCode. I don't see how we can have a functional JDWP and JDI otherwise. The logic above is proving that. It allows for the impossible to support situation where isValueObject() can return true, yet IsSameObject is not supported, meaning we can't properly compute the hash code.

If IsValueObject returns true, the invariant should be that IsSameObject is supported.

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java

plummercj · 2026-01-20T19:25:34Z

src/java.se/share/data/jdwp/jdwp.spec

            (Error VM_DEAD)
        )
    )
+    (Command IsSameObject=11


They might be generic, but they serve no useful purpose outside of valhalla support.

plummercj · 2026-01-20T19:31:21Z

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

-            return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode;
-        } catch (JDWPException exc) {
-            throw exc.toJDIException();
+        if (isValueObject() && vm.canUseIsSameObject()) {


If the JVM supports value objects, the debug agent has to support IsSameObject and ObjectHashCode. I don't see how we can have a functional JDWP and JDI otherwise. The logic above is proving that. It allows for the impossible to support situation where isValueObject() can return true, yet IsSameObject is not supported, meaning we can't properly compute the hash code.

If IsValueObject returns true, the invariant should be that IsSameObject is supported.

plummercj · 2026-01-20T19:38:11Z

test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java

+The test reproduces scenarios when ObjectReference for value object is fetched during the object construction
+and the object content is changed later. When "this" ObjectReference for value object is requested,
+JDI returns existing reference if there are other references to the equal value object or create a new one otherwise.
+The test debugs "new Value(3,6)" statement by setting breakpoints in Value class constructor at locations
+when the object being constructed is (0,0), (3,0) and (3,6).
+
+Test scenarios are defined by test arguments; TestScaffold passes them creating debuggee process (TargetApp class).
+Debugsee initializes static fields with value objects (0,0), (3,0), (3,6) depending on the passed arguments.
+Debugger gets ObjectReferences for the fields before testing.
+
+Tested scenarios:
+- no existing references;
+- all 3 references exists;
+- there are references for 1 and 3 breakpoints.
+


These comment lines should all start with a "*".

sspitsyn · 2026-01-21T04:25:26Z

src/java.se/share/data/jdwp/jdwp.spec

+            (Error INVALID_OBJECT)
+            (Error VM_DEAD)
+        )
+    )


As we discussed, "since" is needed and with possible preview comment (check what we had for Loom preview).

sspitsyn · 2026-01-21T04:27:44Z

src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java

+    public boolean canUseIsSameObject() {
+        return versionInfo().jdwpMajor >= 27;
+    }
+


Nit: We may want to generalize this with something like 'maySupportValueClasses()'.

I'm not so sure this API is really even needed. I don't believe the current calls to it are valid.

sspitsyn · 2026-01-21T04:31:41Z

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java

+                } catch (JDWPException exc) {
+                    throw exc.toJDIException();
+                }
+            }


Nit: The lines 164, 177 can be simplified a little bit with move of the renamed vm.canUseIsSameObject() check equivalent to the isValueClass().

If Valhalla is not supported on the target VM, there is no way for isValueClass() or isValueObject() to ever return true. If Valhalla is supported, they can return true, and we have to assume that JDWP and the debug agent support Valhalla also. We can't have Valhalla support in the JVM and not also have it in JDWP and the debug agent. The debugger/JDI will break if isValueObject() returns false for a value object.

alexmenkov added 3 commits December 18, 2025 11:51

ctor_debug

1d883c2

Revert "ctor_debug"

207aca4

This reverts commit 1d883c2.

fix

88ac48b

alexmenkov marked this pull request as draft December 18, 2025 20:00

plummercj reviewed Dec 18, 2025

View reviewed changes

alexmenkov added 2 commits December 18, 2025 12:41

tabs

ff1803d

Merge branch 'openjdk:lworld' into lworld

32ea988

sspitsyn reviewed Dec 18, 2025

View reviewed changes

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c Show resolved Hide resolved

alexmenkov added 7 commits January 5, 2026 12:39

Merge branch 'openjdk:lworld' into lworld

a5edf06

Merge branch 'openjdk:lworld' into lworld

c46ea6a

Merge branch 'openjdk:lworld' into lworld

576fc6a

fix

549e6a7

tabs

96b3321

IsSameObject only for value objects

d58eae4

Merge branch 'ctor_debug' of github.com:alexmenkov/valhalla into ctor…

e0b4df7

…_debug

ObjectReferenceImp.hashCode

f82f5be

alexmenkov changed the title ~~Ctor debug~~ 8373202: [lworld] ObjectReference.equals should follow == semantics for value objects Jan 12, 2026

alexmenkov marked this pull request as ready for review January 12, 2026 21:49

openjdk bot added the rfr Pull request is ready for review label Jan 12, 2026

sspitsyn reviewed Jan 12, 2026

View reviewed changes

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c Show resolved Hide resolved

src/java.se/share/data/jdwp/jdwp.spec Show resolved Hide resolved

sspitsyn reviewed Jan 14, 2026

View reviewed changes

test/jdk/com/sun/jdi/valhalla/CtorDebuggingTest.java Outdated Show resolved Hide resolved

plummercj reviewed Jan 14, 2026

View reviewed changes

src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java Show resolved Hide resolved

ClassTypeImpl.isValueClass, VirtualMachineImpl.canUseIsSameObject

e74a4cf

plummercj reviewed Jan 16, 2026

View reviewed changes

test update

34c9c2b

space

55ba146

plummercj reviewed Jan 20, 2026

View reviewed changes

sspitsyn reviewed Jan 21, 2026

View reviewed changes

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

Are you sure you want to change the base?

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

Conversation

alexmenkov commented Dec 18, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Dec 18, 2025

Uh oh!

openjdk bot commented Dec 18, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

openjdk bot commented Jan 10, 2026

Uh oh!

mlbridge bot commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sspitsyn Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plummercj Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

alexmenkov commented Dec 18, 2025 •

edited by openjdk bot

Loading

mlbridge bot commented Jan 12, 2026 •

edited

Loading

sspitsyn Jan 14, 2026 •

edited

Loading

plummercj Jan 15, 2026 •

edited

Loading