On Fri, 11 Sep 2026 07:10:48 GMT, John R Rose <[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). > > src/hotspot/share/code/aotCodeCache.cpp line 4080: > >> 4078: // Required by initial stubs >> 4079: >> ADD_EXTERNAL_ADDRESS(SharedRuntime::exception_handler_for_return_address); >> // used by forward_exception >> 4080: ADD_EXTERNAL_ADDRESS(CompressedKlassPointers::base_addr()); > > Here’s an overall question/comment about the sequencing of > `ADD_EXTERNAL_ADDRESS`: It looks like the index assigned to each added addr > depend senstively on configuration information, both static build options and > even command line options. What prevents the AP and PR (assembly phase and > production run) from disagreeing on which addr is at which index? (Or would > any such disagreement be benign – which I doubt.) Suppose we had a bug where > there was an undetected config drift in the PR which affected the sequencing > of the addrs; how would such a bug be detected? Crashes? > > If we could use some more "belt and suspenders" redundancy here, I have a > suggestion: Make the length (`_extrs_length`) be part of the AOT cache > config, to be matched between AP and PR. Sample the length at the end of > startup, and maybe a few other places (since startup has predictable phases). > Make sure the expected length, observed in the AP, shows up in the PR. In current code I found this code which makes address table dependent on the VM config: if (ValueTypeReturnedAsFields) { ADD_EXTERNAL_ADDRESS(SharedRuntime::store_value_type_fields_to_buf); } So we already have this problem in the current code base. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30778#discussion_r3989913294
