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