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

[Serguei Spitsyn]

On Wed, 14 Jan 2026 04:22:42 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 171:
> 
>> 169:     public int hashCode() {
>> 170:         try {
>> 171:             return JDWP.ObjectReference.ObjectHashCode.process(vm, this).hashCode;
> 
> Don't we want to limit the slow path to value objects?

> We didn't do similar for Loom related APIs. I looked through the current canXXX list, and they all seem related to JVMTI capabilities, which don't apply to these two APIs. I think the expectation should be that the user checks the JDWP version to determine if it is implemented.

Yes, I remember about Loom. Asked this to be sure we are in sync. I agree with your suggestion.

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

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