RFR: 8349088: De-virtualize Codeblob and nmethod [v6]

[Vladimir Kozlov]

On Thu, 13 Feb 2025 05:14:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Example please.
>
> static Class wrapperClasses = new Class[Number_Of_Kinds];
>     wrapperClasses[NMethodKind] = NMethodBlob.class;
>     wrapperClasses[BufferKind] = BufferBopb.class;
>     ...;
>     wrapperClasses[SafepointKind] = SafepointBlob.class;
> 
> 
> 
>     CodeBlob cb = new CodeBlob(addr);
>     return wrapperClasses[cb.getKind()];

Done.

>> I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned.
>
> I guess my real question is whether or not it can be considered normal behavior to return null. It seems it should never happen, which is why I was suggesting an assert.

With your suggested `wrapperClasses[]` we will get OOB exception. No need separate assert.

>> `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`.
>> Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect.
>
> Ok. Leaving UncommonTrapKind and ExceptionKind uninitialized seems a bit error prone. Perhaps they can be given some sort of INVALID value.

Done. Initialized them to `Number_Of_Kinds + 1`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954886028
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954890522
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954891616