JDK-8150746 : runtime/logging/ItablesTest.java fails with: java.lang.RuntimeException: 'Resolving: klass: ' missing from stdout/stderr
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-02-26
  • Updated: 2017-08-17
  • Resolved: 2016-03-02
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 9
9 b110Fixed
Related Reports
Relates :  
Relates :  
Description
I think runtime/logging/ItablesTest.java has a similar issue as JDK-8144953.  The only occurrence of a "Resolving:" log output is in the interpreter runtime:

$ ack "Resolving:" hotspot/src/
hotspot/src/share/vm/interpreter/interpreterRuntime.cpp
768:      log_develop_trace(itables)("Resolving: klass: %s to method: %s",

If class resolution happens in compiled code this test fails:

...
[0.354s][trace][itables] invokespecial resolved method: caller-class:<NULL>, compile-time-class:java.lang.ThreadGroup, method:java.lang.ThreadGroup.add(Ljava/lang/Thread;)V, method_holder:java.lang.ThreadGroup, access_flags: 
[0.354s][trace][itables] invokespecial selected method: resolved-class:java.lang.ThreadGroup, compile-time-class:java.lang.ThreadGroup, method:java.lang.ThreadGroup.add(Ljava/lang/Thread;)V, method_holder:java.lang.ThreadGroup, access_flags: 
];
 stderr: []
 exitValue = 0

java.lang.RuntimeException: 'Resolving: klass: ' missing from stdout/stderr 

	at jdk.test.lib.OutputAnalyzer.shouldContain(OutputAnalyzer.java:138)
	at ItablesTest.main(ItablesTest.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:804)

Comments
Yes, that would work.
29-02-2016

Turns out the "Resolving: klass" lines only print out stuff from java -version, so they may be AOT compiled. So I'll just delete that line from the test.
29-02-2016

The test passes with $ jtreg -vmoption:-Xcomp ItablesTest.java $ jtreg -vmoption:-Xcomp -vmoption:-XX:-TieredCompilation ItablesTest.java So we're not sure why AOT is different
29-02-2016

Does JVMCI have a duplicate place for class resolution too? What class resolution doesn't go through the interpreter (besides MethodHandles).
29-02-2016