On Thu, 17 Sep 2026 21:31:13 GMT, Vladimir Kozlov <[email protected]> wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update AOT code tests timeout value. Move two tests to tier2 > > @lmesnik I updated tests timeout to 480 and moved 2 recently added tests > which run > 1min to tier2. > When I looked on previous testing logs I noticed that > `aotCode/ATOCodeFlag.java` test which was excluded from tier1 did not run in > tier2. The reason was that I forgot to add it to > `tier1_runtime_appcds_exclude` group. I fixed it in these changes. Hi @vnkozlov, Could you please include the following RISC-V support patch in this PR as well? https://github.com/DingliZhang/jdk/commit/5ee95351ad6902e02605192a610b0ad327792b34 The main changes in the RISC-V backend are: - Patch narrow klass values in `li32` sequences using compressed-klass encoding, and handle full metadata pointers in `movptr1`/`movptr2` sequences. - Emit `la` with relocation information for C2 external address constants, while retaining `mv` for constants without relocations and fake addresses. - Read and write destinations stored in RISC-V address stubs without enabling trampoline owner fixup: the call-to-stub `auipc` pair remains within the same code blob after relocation. - Keep the RVV array hash-code coefficient table relocation at its registered stub entry, then apply the `sizeof(jint)` offset with `addi`. - Apply the same offset-range check when patching and emitting `auipc` pairs, preventing silent truncation of out-of-range offsets. Tested on Linux/RISC-V (SG2044) with a fastdebug build: - `runtime/cds/appcds/aotCache` - `runtime/cds/appcds/aotCode` - `tier1-tier3` The five framework workloads below are those shown in the [AOT code caching performance chart](https://bugs.openjdk.org/secure/attachment/119123/AOTCodeCachingPerformance_for_JEP.png) attached to [JDK-8335368](https://bugs.openjdk.org/browse/JDK-8335368). For performance, I used a release build of this commit on k3 and SG2044, with each measured JVM pinned to two CPUs. The following results are medians of five fresh JVM runs per configuration, normalized independently on each machine to **default = 1000; lower is better**. - **default:** No application AOT cache. - **AOT Cache:** AOT cache with `AOTCodeCaching`, `AOTStubCaching`, and `AOTAdapterCaching` disabled. - **AOT Cache + Code:** The same cache with full AOT code caching enabled. Results on k3 (2 cores): | Workload | default | AOT Cache | AOT Cache + Code | | ----------- | ------: | --------: | ---------------: | | Helidon | 1000 | 351 | 249 | | Micronaut | 1000 | 377 | 287 | | Quarkus | 1000 | 369 | 289 | | Spring Boot | 1000 | 437 | 304 | | PetClinic | 1000 | 498 | 409 | Results on SG2044 (2 cores): | Workload | default | AOT Cache | AOT Cache + Code | | ----------- | ------: | --------: | ---------------: | | Helidon | 1000 | 310 | 209 | | Micronaut | 1000 | 336 | 233 | | Quarkus | 1000 | 309 | 251 | | Spring Boot | 1000 | 397 | 278 | | PetClinic | 1000 | 494 | 363 | AOT Cache + Code improves on AOT Cache for all five applications on both machines. Caches were freshly generated, and diagnostic runs confirmed that AOT Cache + Code restored compiled methods while AOT Cache loaded no AOT code entries. Timings cover process launch through exit, including shutdown, with warmed filesystem caches. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-5746658819
