RFR: 8368095: [leyden] Fix klass dependency recording [v4]

[Vladimir Ivanov]

On Mon, 22 Sep 2025 16:22:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for symptoms. https://github.com/openjdk/leyden/commit/7b7648a4c9f67be509c6fccbcbc0502648388fdc exposed that our dependency recording is not actually accurate. Now that we check that precompiled tasks have dependencies recorded, before we treat class IK as fully initialized, _missing dependencies_ lead to premature replacement of AP4 -> A4, and potential trap from A4.
>> 
>> I see there are several missing things:
>>  1. We need to record dependencies on object klasses as well, not only on plain metadata.
>>  2. Since ciObjectFactory is shared, we need to notice objects/metadata even on cache hits.
>>  3. It looks like we need to observe dependencies even when `cik->is_initialized()` returns `false` at the moment.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Benchmarks
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'premain' into JDK-8368095-klass-dep-fix
>  - Revert "Retract some unneccesary paths"
>    
>    This reverts commit cb48aacac9d7915e6fd890398020442aedac7948.
>  - Retract some unneccesary paths
>  - Revert unnecessary
>  - Fix

Marked as reviewed by vlivanov (Committer).

Thanks for the clarifications, Aleksey.

There's a long-standing issue with how nmethod init dependencies are managed: they are recorded during training run and then left intact throughout assembly phase while compilers try hard to adapt to the exact set of init dependences during archived code generation. 

Ideally, JITs should produce a new set of init dependences based on training data and observations made during AOT compilation. When it comes to init dependencies, there's an important distinction between classes which were eventually initialized and those which were never initialized during training run. In the former case, it's better to record an extra dependency and delay A4 nmethod installation while in the former case an uncommon trap is preferred. (Similar reasoning applies to classes in being_initialized state: if class initialization never finishes, there's no point in recording an init dependency for it.)

For now, proposed fix looks good.

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

PR Review: https://git.openjdk.org/leyden/pull/97#pullrequestreview-3254541385
PR Comment: https://git.openjdk.org/leyden/pull/97#issuecomment-3320742547