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

[Vladimir Kozlov]

On Mon, 10 Feb 2025 03:25:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38:
>> 
>>> 36: public class CodeCache {
>>> 37:   private static GrowableArray<CodeHeap> heapArray;
>>> 38:   private static VirtualConstructor virtualConstructor;
>> 
>> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.
>
> I think I found the answer. Since there is no longer a vtable, TypeDataBase.addressTypeIsEqualToType() will no longer work for Codeblobs. I was wondering if the lack of a vtable might have some negative impact. Glad to see you found a solution. I hope the lack of a vtable does not creep in elsewhere. I know it will have some negative impact on things like the "findpc" functionality, which will no longer be able to tell the user that an address points to a Codeblob instance. There's no test for this, but users might run across it.

> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.

I don't need any more mapping from CodeBlob class to corresponding virtual table name which does not exist anymore. `CodeBlob::_kind` field's value is used to determine which class should be used.

I think `hashMap` is overkill here. I can construct array `Class<?> cbClasses[]` and use `cbClasses[CodeBlob::_kind]` instead of `if/else` in `getClassFor`. But I would still need to check for unknown value of `CodeBlob::_kind` somehow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1949505126