On Thu, 16 Apr 2026 23:09:52 GMT, Vladimir Kozlov <[email protected]> wrote:
> Improve startup and warmup time by making optimized native code for an > application instantly available when the HotSpot Java Virtual Machine starts. > Achieve this by compiling application code to native code in a training run, > storing the native code in the [AOT > cache](https://openjdk.org/jeps/483#Description) for use in subsequent > production runs. > > More details in the [JEP](https://openjdk.org/jeps/544). > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I made some performance tests using https://github.com/quintesse/leyden-perf-test: I used four Quarkus based APIs. JPBRW is a heavy computational mathematical example. The other three are different ORM libraries that connect to a dockerized postgres in the same machine. The idea is to try to compare similar tests on different JDKs. Training was done with 30 000 requests at a maximum of 500 requests/sec. Production is the same: 30 000 requests with a maximum of 500 req/sec. This was done on my laptop, assigning 2 cores to the application. There may be some jitter due to being my laptop, even if I try not to use it during the testing and I assign CPUs exclusively to it. But the trends are clear. **Startup time** Contains initialization time and how long does it take for the first response to arrive. The following graph shows in blue the time in the traditional java (no AOT cache) and the orange shows the percentage it took for startup with AOT cache. <img width="1018" height="756" alt="image" src="https://github.com/user-attachments/assets/239782ed-4bbc-4474-b4c8-f74d4c0a59c5"; /> <img width="1018" height="756" alt="image" src="https://github.com/user-attachments/assets/92f54764-7b70-45a3-b425-3dbd9e2d11d6"; /> <img width="1018" height="756" alt="image" src="https://github.com/user-attachments/assets/e5ff793b-d321-4b40-beaa-9db22f6e6124"; /> The progression from 25 to 26 was good, but the progression from 26 to 27 is very promising! **Response Times** I'm also measuring the individual response times for each test. I'm going to post only comparison between 26 and 27 of some graphs, to not overflow this. Note that X axis is request number, not time. What I want to compare is how fast it is responding to each request, not the throughput. Heavy mathematical example: <img width="1828" height="1630" alt="image" src="https://github.com/user-attachments/assets/06a6d3ba-f231-4aad-99f6-951fa2668508"; /> <img width="1840" height="786" alt="image" src="https://github.com/user-attachments/assets/ebacc1c4-05b2-47f8-b965-1396cf9e85a5"; /> Peak time (response time less than 1ms) with traditional java takes more than 420 requests to reach peak time. JDK26 AOT is fast, around 200 requests in. This PR AOT peak time is reached a bit after the 100 request. So we are halving the time to reach peak time. And even if peak time is not reached after some time, the response times are faster from the beginning, with less jitter. With the rest of the tests the trend is similar. With Tribe KRD, peak time comes earlier in all three cases, but the same trend: <img width="1840" height="1632" alt="image" src="https://github.com/user-attachments/assets/fc133e68-b867-4ff7-a1f9-2a628d200d1b"; /> <img width="1840" height="786" alt="image" src="https://github.com/user-attachments/assets/97a32e0c-2474-40a9-9596-ed2868a59397"; /> @vnkozlov I can give you access to the spreadsheets with numbers if you want. Adding some logging for the map files: https://github.com/vnkozlov/jdk/pull/1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4312010593 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4658109158
