JDK-8265796 : vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with JEP 416
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-04-22
  • Updated: 2021-12-02
  • Resolved: 2021-11-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 b26Fixed
Related Reports
Relates :  
JDK-8271820 - Implementation of JEP 416: Reimplement Core Reflection with Method Handle
Description
vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails when running with the fix for JDK-6824466 [1] 

# ERROR: Unexpected size of ClassLoaderReference.referringObjects: 18, expected: 17
The following stacktrace is for failure analysis.
nsk.share.TestFailure: Unexpected size of ClassLoaderReference.referringObjects: 18, expected: 17
	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:432)
	at nsk.share.Log.complain(Log.java:403)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.checkClassObjectReferrersCount(referringObjects002.java:103)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.doTest(referringObjects002.java:126)
	at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:214)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.run(referringObjects002.java:86)
	at nsk.jdi.ObjectReference.referringObjects.referringObjects002.referringObjects002.main(referringObjects002.java:82)
	at java.base/jdk.internal.reflect.DirectMethodAccessorImpl$StaticMethodAccessor.invoke(DirectMethodAccessorImpl.java:150)
	at java.base/java.lang.reflect.Method.invoke(Method.java:574)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:831)

[1] https://github.com/mlchung/jdk/tree/method-invoke-4
Comments
Changeset: 7cb56a23 Author: Leonid Mesnik <lmesnik@openjdk.org> Date: 2021-11-23 19:27:50 +0000 URL: https://git.openjdk.java.net/jdk/commit/7cb56a230dbd52935ae48fe44b4192ae3b4d7adb
23-11-2021
The extra reference comes from MethodType stored as a weak reference in the MethodType::internTable. The weak reference will be purged when the MethodType becomes unreachable. A better fix may be to force GC such that this weakly referenced MethodType is GC'ed. From Leonid: I think it a link from ‘static final ConcurrentWeakInternSet<MethodType> internTable = new ConcurrentWeakInternSet<>();’ 6:38 Here is the ref tree: instance of java.lang.invoke.MethodType(id=883) instance of java.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry(id=887) instance of java.util.concurrent.ConcurrentHashMap$Node(id=888) instance of java.util.concurrent.ConcurrentHashMap$Node[1024] (id=890) instance of java.util.concurrent.ConcurrentHashMap(id=892) instance of java.lang.invoke.MethodType$ConcurrentWeakInternSet(id=894) instance of java.lang.Class(reflected class=java.lang.invoke.MethodType, id=72)
18-11-2021
w.r.t. the extra reference, is TestClass1 (the class being inspected) being referenced in the signature of any reflective call? Method::invoke will cause a MethodHandle to be created and its associated MethodType will reference the classes in the signature. That may be one possible cause of the extra reference.
13-10-2021
I can only assume by my recent quick look at the test (which I've never looked at before). It looks like it expects 10 references from instances (createInstances is 10), 4 from HeapwalkingDebuggee.includedIntoReferrersCountTypes (see below), and then 3 of these special references as outlined in the comments. I believe HeapwalkingDebuggee.includedIntoReferrersCountTypes is in intended to create one of each of the following references: includedIntoReferrersCountTypes.add(ObjectInstancesManager.STRONG_REFERENCE); includedIntoReferrersCountTypes.add(ObjectInstancesManager.WEAK_REFERENCE); includedIntoReferrersCountTypes.add(ObjectInstancesManager.SOFT_REFERENCE); includedIntoReferrersCountTypes.add(ObjectInstancesManager.PHANTOM_REFERENCE); So that's 17 references, and with the JDK-6824466 changes it appears we now have 18. We might need to modify the test to give info on the references. The counting is done in checkClassObjectReferrersCount() by calling ClassObjectReference.referringObjects(). Perhaps a first step in figuring out what is going on here is to call and print the result of ObjectReference.referenceType() for each referring object returned.
23-04-2021
Thanks Chris. FWIW. JDK-6824466 also makes MethodHandle::asTypeCache to a weak reference which may be related.
23-04-2021
What references is this test tracking? JDK-6824466 removes the DelegatingClassLoader objects.
22-04-2021
// each class instances has reference to class object + // + 'includedIntoReferrersCountTypes.size()' referrers was additionally created // +1 referrer is classloader // +1 referrer is debugee class unloader // +1 self-reference from this_class index int expectedReferrersCount = createInstances + HeapwalkingDebuggee.includedIntoReferrersCountTypes.size() + 3; I assume JDK-6824466 is adding to the list of +1 additional references, in which case just change the 3 to a 4, but it would be nice to document the cause of this +1. However, I question a test even having this much knowledge of JDK internals. Perhaps there is a way to compute the expected additional references by just looking at how many there are for the class before any instances are created.
22-04-2021