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

[Chris Plummer]

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

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

I'm not sure what your backward compatible question is. I think we need an API to determine if a ClassType is a value type or not. This could be expensive to maintain. Probably we need to only look it up when needed and can keep it cached with the ClassType. Another option is to only try to avoid the IsSameObject callback when we are not dealing with an ObjectReferenceImpl subclass. We can make a check something like `obj.getClass() == ObjectReferenceImpl.class`. When they are not equal, then we are dealing with a subclass that we know can't be a value type.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1834#discussion_r2633578296