On Thu, 18 Dec 2025 20:38:46 GMT, Alex Menkov <[email protected]> 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
