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

[David Holmes]

On 9/03/2021 4:20 pm, Ioi Lam wrote:
> 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?
> 
> In tiered testing, we run many tests with additional options that will significantly slow down execution. E.g., `jtreg -vmoption:-Xcomp`.
> 
> The OldClassTest class is like a shell script. It builds the "Hello" class using ASM, and then launch a child process to do the real test. So it doesn't make sense to enable -Xcomp when running OldClassTest.
> 
> Our policy is to use `@run driver` for classes like OldClassTest. This improves test execution when complicated `-vmoptions` are used.
> 
> Changing the test to `@run main` will work around the jtreg bug, but this will slow down test execution. Since a new version of jtreg will be released soon, we shouldn't apply this work around.

I think it is also accurate to say that the command-line flags implied 
by @module commands are distinct from the "VM options" that otherwise 
get passed through (or not) depending on the exact mode of operation. 
IIUC the options implied by @module commands should always be passed - 
and that is the bug that is being fixed.

Cheers,
David

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