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

[Chris Plummer]

On Fri, 16 Jan 2026 00:01:54 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
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassTypeImpl.isValueClass, VirtualMachineImpl.canUseIsSameObject

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

> 175:     @Override
> 176:     public int hashCode() {
> 177:         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.

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

> 837: 
> 838:     public boolean canUseIsSameObject() {
> 839:         return versionInfo().jdwpMajor >=27;

Missing a space before 27.

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

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