RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
Vladimir Kozlov
kvn at openjdk.org
Tue Feb 18 19:24:22 UTC 2025
On Wed, 12 Feb 2025 03:03:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Before I forgot to answer you, @plummercj
>> I completely agree with your comment about cleaning up wrapper subclasses which do nothing.
>>
>> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?
>>
>> An other purpose could be a place holder for additional information in a future which never come.
>>
>> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.
>>
>> So yes, feel free to clean this up. I will help with review.
>
>> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?
>
> Possibly getName() didn't exist when PStack was first written. It would be good if PStack not only included the type name as it does now, but also the actual name of the blob, which getName() would return.
>
>> An other purpose could be a place holder for additional information in a future which never come.
>
> Yes, and you also see that with the Observer registration and the `Type type = db.lookupType(<typename>)` code, which are only needed if you are going to lookup fields of the subtypes, which most don't ever do, yet they all have this code.
>
>> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.
>
> Yeah, that's not working right for CodeBlob subtypes that are not RuntimeStubs. Easy to fix though.
>
>> So yes, feel free to clean this up. I will help with review.
>
> Ok. Let me see where things are at after you are done with the PR.
Thank you, @plummercj , for review.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2666228333
More information about the hotspot-compiler-dev
mailing list