RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
Vladimir Kozlov
kvn at openjdk.org
Thu Feb 13 17:29:14 UTC 2025
On Thu, 13 Feb 2025 17:22:18 GMT, John R Rose <jrose at openjdk.org> wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>
>> rename SA argument
>
> One related idea: The Vptr classes seem to be regular enough to be templated. That is, one class body, instantiated with a template argument for each code blob type (and probably another for the enum). That would remove some of the distracting per-class boilerplate. Something like:
>
>
> template<typename CB_T, CodeBlob::Kind Tkind>
> class Vptr_Impl : public Vptr {
> override void print_on(const CodeBlob* instance, outputStream* st) const {
> assert(instance->kind() == Tkind, "sanity");
> ((const CB_T*)instance)->print_on_impl(st);
> }
> …
> override bool assert_sane(cosnt CodeBlob* instance) {
> assert(instance->kind() == Tkind, "");
> return true;
> }
> };
>
> class CodeBlob {
> public:
> final Vptr* vptr() const {
> Vptr* vptr = vptr_array[_kind];
> assert(vptr->assert_sant(this), "correct array element");
> return vptr;
> }
> final void print_on(outputStream* st) const {
> vptr()->print_on(this, st);
> }
> };
>
>
> Then:
>
>
> const Vptr* array[] = {
> &Vptr_Impl<CodeBlob, CodeBlobKind>(),
> ...
> &Vptr_Impl<UncommonTrapBlob, UncommonTrapKind>(),
> ...
> };
>
>
> The array could be filled by a macro that tracks the enum members; I like that as a small job for macros (no code in it).
>
> Then:
>
>
> class UncommonTrapBlob : public OtherBlob {
> protected: // impl "M" method is not public
> void print_on_impl(outputStream* st) const {
> OtherBlob::print_on_impl(st);
> st->print("my field = %d", _my_field);
> }
> // Vptr needs to call impl method
> friend class Vptr_Impl; // this might break down, so make it all public in the end
> };
>
>
> I don't see any reason the Vptr subclasses need to be related in any more detail as subs or supers.
>
> Well, C++ is a bag of surprises, so there are probably several reasons the above sketch is wrong. But something like it might add a little more readability and predictability to the code.
Thank you, @rose00 and @xmas92, for review and suggestions.
Let me say it first - printing code for code blobs and nmethod is big mess. It requires separate big change to clean it up.
For example, I have to go through CodeBlob's virtual dispatch `print_value_on_v()` for nmethod because some sets of `nmethod::print*()` are defined only in debug VM: [nmethod.hpp#L919](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.hpp#L919)
Then `nmethod` has other mess which requires C++ trickery because it does not follow print API in CodeBlob:
void print(outputStream* st) const;
// need to re-define this from CodeBlob else the overload hides it
void print_on(outputStream* st) const override { CodeBlob::print_on(st); }
void print_on(outputStream* st, const char* msg) const;
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657282969
More information about the serviceability-dev
mailing list