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

[Coleen Phillimore]

On Tue, 14 Dec 2021 02:32:54 GMT, David Holmes <dholmes 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).
>
> 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?

VM_Version::initialize() is called very early in Threads::create_vm.  This latter VM_Version::initialize_cpu_information is called later when JFR event is emitted.  The reason it was "_ext" was because it is part of JFR only.  It seems that we might be able to consolidate this more now that it's moved later.
I don't think adding an assert would be meaningful here.

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

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