RFR: 8315576: compiler/codecache/CodeCacheFullCountTest.java fails after JDK-8314837 [v2]

Tobias Hartmann thartmann at openjdk.org
Wed Sep 20 11:49:39 UTC 2023


On Fri, 8 Sep 2023 01:35:18 GMT, Yi-Fan Tsai <duke at openjdk.org> wrote:

>> CodeCacheFullCountTest disables code cache flushing, and loads classes to fill up the code cache.
>> The test expects two scenarios: 1) the compilers are disabled, adapters could still be created, and the process continues and terminates normally or 2) the adapters cannot be allocated and VirtualMachineError has been thrown and printed to stderr.
>> 
>> When the test runs with option `-Xcomp`, `-esa`, and `-XX:-TieredCompilation`, more codes are compiled and the code cache becomes full earlier.
>> 
>> The bug report (windows-x64) looks unable to allocate the adapters and throwing VirtualMachineError during initialization of VM. The stack trace is printed to tty/stdout (`vm_exit_during_initialization`) rather than stderr.
>> 
>> The bug could also be reported on linux-x64. The adapters could not be allocated in `loadClass`, and VirtualMachineError has been thrown and wrapped in other exceptions (e.g. LambdaConversionException in `InnerClassLambdaMetafactory.buildCallSite` and then BootstrapMethodError in `BootstrapMethodInvoker.invoke`). The stack trace might not be completely printed  in `ThreadGroup.uncaughtException` while the code cache is full. Another VirtualMachineError might be thrown by e.g. `java.lang.StackTraceElement` and eventually printed by `JavaThread::exit` without its message. 
>> 
>>  stderr: [OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
>> OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
>> OpenJDK 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
>> Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception
>> 
>> Exception: java.lang.VirtualMachineError thrown from the UncaughtExceptionHandler in thread "main"
>> ]
>> 
>> 
>> In summary, exception handling after full code cache is inconsistent and expecting the scenario 2 is unreliable. The check is removed.
>> 
>> The test has passed as below.
>> 
>> make test \
>>     TEST="test/hotspot/jtreg/compiler/codecache/CodeCacheFullCountTest.java" \
>>     JTREG="JAVA_OPTIONS=-Xcomp -ea -esa -XX:-TieredCompilation"
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the test from ProblemList-Xcomp.txt

What about handling it in the same way the method handle tests do?
https://github.com/openjdk/jdk/blob/e1870d360e05c372e672b519d7de2a60c333675b/test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/CodeCacheOverflowProcessor.java#L28-L34

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

PR Comment: https://git.openjdk.org/jdk/pull/15604#issuecomment-1727566485


More information about the hotspot-compiler-dev mailing list