On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot,
>> but most of it is unnecessary. The generic CodeBlob class can handle all
>> support needed by most of the subclasses. The only subclasses we need to
>> keep around around NMethod, RuntimeStub, and UpcallStub, since they all have
>> special support in SA. I also kept around RuntimeBlob so RuntimeStub can
>> continue to inherit from it and be consistent with hotspot, but it's not
>> actually necessary, and I'm more than happy to remove it also.
>>
>> I also cleaned up the PStack support for CodeBlobs. It can just use
>> CodeBlob.getName() rather than trying to figure out the type of the CodeBlob
>> instance to print out type name. This allows us to get rid of most isXXX()
>> APIs. It also provides more useful output in some cases.
>>
>> There is some minor loss of functionality in some of the CodeBlob subtypes I
>> removed. For example this is what AdapterBlob.getName() looked like (it is
>> now gone):
>>
>>
>> public String getName() {
>> return "AdapterBlob: " + super.getName();
>> }
>>
>>
>> So now we just use the default CodeBlob.getName(), which is what
>> super.getName() would up execute. I think for AdapterBlob this always
>> returns "I2C/C2I adapters", so now you only get this rather than
>> "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail
>> with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and
>> VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob
>> types getName() will no longer include the CodeBlob type. I could special
>> case them in CodeBlob.getName() by fetching the kind to determine what the
>> proper name should be. Let me know if you think it is worth it.
>
> Chris Plummer has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Minor improvements.
Thanks for the reviews Vladimir and Serguei!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2675336648
