RFR: 8202579: Revisit VM_Version and VM_Version_ext for overlap and consolidation

[David Holmes]

On Mon, 13 Dec 2021 23:14:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change makes VM_Version_Ext part of VM_Version (the platform dependent part) and moves some duplicated code.  x86 had the most code in VM_Version_Ext, so the most code moved there. There might be some unneeded functions but I didn't want to remove them with this change.
> 
> Tier1 (tier2-4 testing in progress) on linux and windows for x86, aarch64, Oracle platforms and tested builds on:
> linux-aarch64-debug,linux-x86-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
> and
> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug
> 
> Ran JFR tests manually (it uses os_perf* CPUInformationInterface code).

Hi Coleen,

The code relocation seems okay. Good cleanup!

One query below on `CPUInformationInterface::initialize()`.

Good catch on the `Abstract_VM_Version` calls in jvm.cpp! I missed that in the review of JDK-8241071.

Thanks,
David

src/hotspot/os/linux/os_perf_linux.cpp line 929:

> 927: bool CPUInformationInterface::initialize() {
> 928:   _cpu_info = new CPUInformation();
> 929:   VM_Version::initialize_cpu_information();

I can't figure out when this code will actually get executed in  relation to the VM initialization process and VM_Version's initialization. Can this actually execute before that happens? Or could we assert that it has happened?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6820