On Tue, 14 Dec 2021 02:32:54 GMT, David Holmes <[email protected]> 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
