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

[Chris Plummer]

On Thu, 18 Dec 2025 20:00:45 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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

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

> 148:     public boolean equals(Object obj) {
> 149:         if (obj instanceof ObjectReferenceImpl other) {
> 150:             if (ref() == other.ref() && super.equals(obj)) {

I'm wondering if the super.equals(obj) call is necessary. The way JDI is implemetned, there is a 1-to-1 relationship between the ObjectID and the ObjectReference. If the ObjectIDs match, then the ObjectRefernces instances should be one in the same. So either one of these checks should be sufficient. I don't think both are needed.

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

> 157:             } catch (JDWPException exc) {
> 158:                 throw exc.toJDIException();
> 159:             }

So the downside here is that when we don't have equality w.r.t. ObjectIDs, we do the heavyweight call over JDWP. A while back I did a scan of users of equals() in the JDI implementation and jdb, and it seemed it was always done on known subtypes (ClassLoaderReference, ThreadReference, ClassReference, etc). So I doubt in practice you would ever see two value types being compared, unless the debugger was doing it for some reason. So if you did limit this JDWP call to value types, probably it would be rare to non-existent that it would ever be called.

src/jdk.jdwp.agent/share/native/libjdwp/ObjectReferenceImpl.c line 410:

> 408: 
> 409:     ref = commonRef_idToRef(env, id);
> 410:     (void)outStream_writeInt(out, objectHashCode(ref));

Interesting that the debug agent already has an objectHashCode() but there were no users of it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632512266
PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632527382
PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632506961