RFR: Restore Method pointer for every AOTCodeEntry [v3]

[Ashutosh Mehra]

On Mon, 11 Aug 2025 20:27:09 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> There was a recent commit [0] that included code to invalidate preload entry when invalidating a normal `AOTCodeEntry`. This is done by reaching out to the preload entry through the normal `AOTCodeEntry::_method`:
>> 
>> https://github.com/openjdk/leyden/blob/7b7648a4c9f67be509c6fccbcbc0502648388fdc/src/hotspot/share/code/aotCodeCache.cpp#L1056-L1070
>> 
>> But unfortunately `AOTCodeEntry::_method` is restored only for the entries marked for preload:
>> https://github.com/openjdk/leyden/blob/7b7648a4c9f67be509c6fccbcbc0502648388fdc/src/hotspot/share/code/aotCodeCache.cpp#L1938-L1939
>> 
>> This PR fixes this bug by restoring `AOTCodeEntry::_method` for all AOTCodeEntry-s. This is achieved by using AOTCache's pointer bitmap to track `AOTCodeEntry::_method`. It removes the need to store method offset separately in the AOTCodeEntry.
>> It also fixes a couple of related bugs:
>> 1. In `AOTCodeCache::finish_write()` it is possible that the AOTCodeEntry array is not properly aligned.
>> 2. When invalidating a preload entry, it is possible that the entry has not been loaded. This triggers the assert that expects an entry to be invalidated is always loaded.
>> 
>> [0] https://github.com/openjdk/leyden/commit/392fbbb1859cd71521cb915b601a65cf59ba495b
>
> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'premain' into set-method
>  - Store offset of AOTCodeEntry array
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Restore Method* for every AOTCodeEntry
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

hmm after the merge I see tier1 runtime tests failing unexpectedly. There is no test failure as such.


2025-08-11T21:30:13.6135284Z make[2]: *** [RunTests.gmk:1247: run-test-jtreg_test_hotspot_jtreg_tier1_runtime] Terminated
2025-08-11T21:30:13.6143366Z make[1]: *** [make/RunTestsPrebuilt.gmk:300: test-prebuilt] Terminated
2025-08-11T21:30:13.6154618Z make: *** [/home/runner/work/leyden/leyden/make/Global.gmk:124: test-prebuilt] Terminated
2025-08-11T21:30:13.7644741Z ##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
2025-08-11T21:30:13.7646269Z ##[error]Process completed with exit code 143.
2025-08-11T21:30:14.1095540Z Cleaning up orphan processes


Same failure was seen in the PR for storing cpu features in AOTCodeCache (see https://github.com/openjdk/leyden/pull/84#issuecomment-3168208298).
And the lastest merge pulled in these changes into this PR. It can't be just a coincidence. There is something that GHA testing does not like about cpu feature caching.

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

PR Comment: https://git.openjdk.org/leyden/pull/90#issuecomment-3177025077