RFR: 8263158: [TESTBUG] FAILED: runtime/cds/appcds/OldClassTest.java

Yi Yang yyang at openjdk.java.net
Tue Mar 9 02:16:05 UTC 2021


On Mon, 8 Mar 2021 21:34:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> runtime/cds/appcds/OldClassTest.java failed due to the following reason:
>> 
>> java.lang.IllegalAccessError: superinterface check failed: class OldClassTest (in unnamed module @0x28115522) cannot access class jdk.internal.org.objectweb.asm.Opcodes (in module java.base) because module java.base does not export jdk.internal.org.objectweb.asm to unnamed module @0x28115522
>> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1010)
>> at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>> at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:855)
>> at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:753)
>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:676)
>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
>> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>> at java.base/java.lang.Class.forName0(Native Method)
>> at java.base/java.lang.Class.forName(Class.java:471)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
>> at java.base/java.lang.Thread.run(Thread.java:831)
>> STATUS:Failed.`main' threw exception: java.lang.IllegalAccessError: superinterface check failed: class OldClassTest (in unnamed module @0x28115522) cannot access class jdk.internal.org.objectweb.asm.Opcodes (in module java.base) because module java.base does not export jdk.internal.org.objectweb.asm to unnamed module @0x28115522
>> 
>> This test case has failed on my machine for a long while, I don't see other reports on JBS nor PRs. Please let me know if I missed some stuff.
>> 
>> Thanks!
>> Yang
>
> Upon more investigation, we determined that the problem is in jtreg's handling of `@run driver` in `jtreg -othervm` mode. This should be fixed in the upcoming release of jtreg.
> 
> Since this issue affects not just OldClassTest.java, I don't recommend fixing this test case individually. Instead, I would recommend using `jtreg -agentvm` as a work around for now.

According to @iklam's suggestion, I can withdraw this PR. But I'm more confused than before..

I found the following [JTREG doc](https://openjdk.java.net/jtreg/faq.html#what-are-the-agentvm-and-othervm-modes) which says:
> In otherVM mode, jtreg will start a new JVM to perform each action (such as @compile, @run main, and so on) in a test. When the action has been completed, the JVM will exit, relying on the system to cleanup any resources that may have been in use by the action.

> In agentVM mode, jtreg will maintain a pool of available JVMs, grouped according to the VM options specified when the JVM was created. When jtreg needs to execute an action for a test, it will obtain a suitable JVM from the pool, or create a new one if necessary. jtreg will use that JVM, and when it has been completed, it will attempt to restore some well-known global values to a standard state (such as the system properties, standard IO streams, security manager, etc). If that cleanup is successful, depending on the VM options used to create the JVM, jtreg may put the JVM in the pool for later reuse. Otherwise, the JVM is allowed to exit.

In summary, otherVM starts a new JVM to perform actions such as `@compile` and `@run main` In agentVM mode, jtreg obtains a suitable JVM from the pool. So it looks whether agentVM or otherVM should not affect this test cast since it occurred due to missing `--add-opens` options.

Another [JTREG doc](https://openjdk.java.net/jtreg/faq.html#what-are-the-agentvm-and-othervm-modes) says:
> jtreg provides a variant of @run main that can be useful in such situations: @run driver. This is the same as @run main with the exception that any VM options specified on the command line will not be used when running the specified class.

This is actually what we want, so just using '@run main` looks enough for this test case?

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

PR: https://git.openjdk.java.net/jdk/pull/2866


More information about the hotspot-runtime-dev mailing list