RFR: 8319932: [JVMCI] class unloading related tests can fail on libgraal

[Doug Simon]

On Wed, 28 Feb 2024 12:45:17 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR addresses a race in `runtime/ClassInitErrors/InitExceptionUnloadTest.java` that is exposed by libgraal which sets the [default value for `TypeProfileWidth` to 8](https://github.com/openjdk/jdk/blob/eb4b6fa6212380c9b6d3c94f5aa3384f12a0c125/src/hotspot/share/compiler/compilerDefinitions.cpp#L429).
> 
> The problem is as follows:
> * The type `InitExceptionUnloadTest$SpecialException` is loaded by a [custom class loader](https://github.com/openjdk/jdk/blob/eb4b6fa6212380c9b6d3c94f5aa3384f12a0c125/test/hotspot/jtreg/runtime/ClassInitErrors/InitExceptionUnloadTest.java#L106) and appears in the profile of `String.valueOf` as shown by `-XX:+PrintMethodData`:
> 
> static java.lang.String::valueOf(Ljava/lang/Object;)Ljava/lang/String;
>   interpreter_invocation_count: 957
>   invocation_counter: 957
>   backedge_counter: 0
>   decompile_count: 0
>   mdo size: 496 bytes
> 
>    0 nofast_aload_0
>    1 ifnonnull 10
>   0 bci: 1 BranchData taken(698) displacement(56)
>                                     not taken(0)
>    4 fast_aldc_w "null"
>    7 goto 14
>   32 bci: 7 JumpData taken(0) displacement(168)
>   10 nofast_aload_0
>   11 invokevirtual 1023 <java/lang/Object.toString()Ljava/lang/String;>
>   56 bci: 11 VirtualCallData count(2) entries(8)
>                                     'java/lang/String'(470 0.67)
>                                     'java/lang/StackTraceElement'(204 0.29)
>                                     'java/lang/Error'(1 0.00)
>                                     'java/lang/NoClassDefFoundError'(6 0.01)
>                                     'java/lang/ExceptionInInitializerError'(8 0.01)
>                                     'InitExceptionUnloadTest$SpecialException'(2 0.00)          <===== unloadable type in profile
>                                     'java/lang/OutOfMemoryError'(2 0.00)
> 
> 
> * Types in profiles are cleaned by parallel GC worker threads when ZGC or G1 is in use. This is shown by this native stack trace:
> 
> Current thread (0x000000013ee0a660): WorkerThread "GC Thread#0" [id=13315, stack(0x000000016bb8c000,0x000000016bd8f000) (2060K)]
> Stack: [0x000000016bb8c000,0x000000016bd8f000], sp=0x000000016bd8eb80, free space=2058k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.dylib+0x7d8680] ReceiverTypeData::clean_weak_klass_links(bool)+0x170
> V [libjvm.dylib+0x7dc428] MethodData::clean_method_data(bool)+0x7c
> V [libjvm.dylib+0x4905d0] InstanceKlass::clean_weak_instanceklass_links()+0x54
> V [libjvm.dylib+0x84a6c0] KlassCleaningTask::work()+0...

Libgraal testing both with and without `-Xcomp` shows that this test now passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18044#issuecomment-1969144581