On Mon, 10 Feb 2025 03:25:30 GMT, Chris Plummer <[email protected]> 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
