RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64

[Erik Gahlin]

I haven't looked at the code closely., but we definitely want this 
information in JFR, as a separate RFE of course. Any API that will make 
it easy to access the information later as char* is appreciated, i.e.

EventOSInformation event;
event.set_virtualization(Virtualization::name());
event.commit();

Thanks
Erik

> On 4/04/2019 10:35 pm, Baesken, Matthias wrote:
>>>
>>> On 4/04/2019 8:54 pm, Baesken, Matthias wrote:
>>>>>
>>>>> My remaining query is why we need the OS specific checks and code in
>>>>> os-cpu files? Isn't this just cpu specific? Even if a particular OS
>>>>> doesn't support virtualization, won't the cpuid query simply 
>>>>> report "no
>>>>> virtualization"?
>>>>>
>>>>
>>>> Hi David,  if you are referring to  these  os-cpu files  :
>>>>
>>>> src/hotspot/os_cpu/linux_x86/vm_version_linux_x86.cpp
>>>> src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp
>>>>
>>>> we have different coding available  because  I am not aware of a 
>>>> cross OS
>>> API/coding to get   the cpu id info.
>>>> That’s why different coding for LINUX/Windows.
>>>
>>> ?? But there's nothing in those added functions that is Linux specific
>>> or Windows specific! The only difference is the mechanism for doing
>>> "inline assembly" and that's compiler specific. So this should just use
>>> compiler based ifdefs in vm_version_x86.cpp.
>>>
>>
>> Hi David, I see your point.  But I thought we want to reduce the  
>> ifdefs and favor  putting code into the os or os/cpu specific  files .
>> But it is true , from a technical point  we could do using the 
>> compiler macros .
>
> I favour putting os-specific code in os-specific files over OS ifdefs 
> in shared files. But here we are talking about compiler-specific code 
> that is also CPU specific (not os specific). So compiler ifdefs in the 
> cpu files is the way to handle this.
>
> Thanks,
> David
>
>> Best regards, Matthias
>>