On Mon, 10 Feb 2025 16:57:18 GMT, Vladimir Kozlov <k...@openjdk.org> wrote:
>>> 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. > >> impact on things like the "findpc" functionality > > Do you mean `findpc()` function in VM which is used in debugger? Nothing > should be changed for it. > It calls `os::print_location()` which calls `CodeBlob::dump_for_addr(addr, > st, verbose);`: > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/os.cpp#L1278 Actually I was referring to the clhsdb findpc command, which uses PointerFinder, but actually that should be ok because it special cases the codecache and knows how to find CodeBlobs in it. It's the clhsdb "inspect" command that will no longer be able to identify the type for an address that points to the start of a CodeBlob. This is true of any address that points to the start of a hotspot C++ object that does not have a vtable, or is not declared in vmstructs. So it's not a new issue, but is just adding more types to the list that "inspect" won't figure out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954906641
