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

[Chris Plummer]

On Fri, 16 Jan 2026 22:19:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> 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.
>
> We should execute jdwp command only when it's available (vm.canUseIsSameObject returns true) and the object is value object.
> Note that isValueObject() may not work for old releases, so we need to check both conditions here or move version check to ClassTypeImpl.isValueClass

If the JVM supports value objects, the debug agent has to support IsSameObject and ObjectHashCode. I don't see how we can have a functional JDWP and JDI otherwise. The logic above is proving that. It allows for the impossible to support situation where isValueObject() can return true, yet IsSameObject is not supported, meaning we can't properly compute the hash code.

If IsValueObject returns true, the invariant should be that IsSameObject is supported.

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

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