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

[Alex Menkov]

On Thu, 18 Dec 2025 20:20:51 GMT, Chris Plummer <cjplummer 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.

I agree that super.equals call is not necessary, just kept it as it was

> 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.

agreed. Do I understand correctly that I cannot modify existing command (jdwp protocol shoul be backward compatible?) to get classes and need a new one to check if the class is value class?

> 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.

`ObjectReferenceImpl.hashCode()` calculates it by itself from objectID (it should call objectHashCode)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632546790
PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632555234
PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2632560792