RFR 7041262: VM_Version should be called instead of Abstract_VM_Version so that overriding works (original) (raw)

David Holmes david.holmes at oracle.com
Tue Oct 16 02:27:14 UTC 2018

Hi Kim,

On 16/10/2018 10:58 AM, Kim Barrett wrote:

On Oct 15, 2018, at 6:58 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

Stupid question. Why keep empty static methods in AbstractVMVersion which are never used? The empty methods are the defaults, for platforms that don’t extend or override the behavior.

Sorry basic C++ question: so if we have

class Base { public: static void init() { } }

class Derived : public Base { }

and some other code has:

Derived::init();

then this is legal and calls base::init() ?

For example, only sparc currently extends initbeforeergo. For all other platforms, the empty default is used. arm is the only implementor of earlyinitialize. It does look like every platform implements initialize, but I think the empty Abstract method should be kept for consistency, and as the place to hang the documentation comment.

The thing I’m confused about is how VMVersionExt fits into this scheme. But that’s out of scope for Harold’s change, which looks good to me.

VM_Version_Ext was a hook for addition hardware information that was (mostly?) empty in the open code and did its thing in the closed code for JFR. Now JFR is open it became open too - and there is an open JBS issue to reconcile it with VM_Version.

Thanks, David

More information about the hotspot-runtime-dev mailing list