Hi Yasumasa , I'm more or less fine with the change .
But still not fully convinced that removing the iteration is a good thing .
http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html
1827 for (base = 0x4000; base < 0x4001; base
On 12/08/2020 8:51 pm, Baesken, Matthias wrote:
Hi Yasumasa , I'm more or less fine with the change .
But still not fully convinced that removing the iteration is a good thing .
http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html
1827
Hi Matthias, David,
On 2020/08/12 21:12, David Holmes wrote:
On 12/08/2020 8:51 pm, Baesken, Matthias wrote:
Hi Yasumasa , I'm more or less fine with the change .
But still not fully convinced that removing the iteration is a good thing .
http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/web
Hi Yasumasa,
On 12/08/2020 10:56 pm, Yasumasa Suenaga wrote:
Hi Matthias, David,
On 2020/08/12 21:12, David Holmes wrote:
On 12/08/2020 8:51 pm, Baesken, Matthias wrote:
Hi Yasumasa , I'm more or less fine with the change .
But still not fully convinced that removing the iteration is a goo
Hi David,
thanks for your good questions. I had also started to look at it and had
similar thoughts.
If we want to reduce overhead, inline assembler / intrisics will be better than
creating a stub in the code cache.
I think the existing inline assembler implementation for linux should also work
> And on Windows, there's a __cpuid intrinsic available. (I have never tried
> it.)
Hi Martin, we use this intrinsic in "our" JVM so yes it works .
> Nevertheless, I appreciate improvements in virtualization detection.
> Sometimes, problems or crashes are related to the virtualization layer,
>I understand that if the process runs on Xen on other hypervisor (e.g. KVM),
>information for Xen would be set between 0x4100 and 0x4001.
>Ok, I will not remove the loop in new webrev, and will add comment about it.
Hi Yasumasa , thanks !
Regarding the WMI overhead , if you could get
Hi Matthias, David,
I measured startup benchmarks with `Measure-Command
{.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}`
on PowerShell.
* PC: Ryzen 3 3300X, 16GB memory
* OS: Windows 10 x64 (May 2020 Update)
* Java: jdk/jdk revision 60537
(Compiled by VS 2019
On 13/08/2020 11:12 am, Yasumasa Suenaga wrote:
Hi Matthias, David,
I measured startup benchmarks with `Measure-Command
{.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
--version}` on PowerShell.
* PC: Ryzen 3 3300X, 16GB memory
* OS: Windows 10 x64 (May 2020 Update)
* Java
On 2020/08/13 11:54, David Holmes wrote:
On 13/08/2020 11:12 am, Yasumasa Suenaga wrote:
Hi Matthias, David,
I measured startup benchmarks with `Measure-Command
{.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe --version}`
on PowerShell.
* PC: Ryzen 3 3300X, 16GB memory
* OS
On 13/08/2020 2:15 pm, Yasumasa Suenaga wrote:
On 2020/08/13 11:54, David Holmes wrote:
On 13/08/2020 11:12 am, Yasumasa Suenaga wrote:
Hi Matthias, David,
I measured startup benchmarks with `Measure-Command
{.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe
--version}` on Po
>
>Should we make the change to determine just before it is needed (e.g. VM.info
>or hs_err log) at first?
>It is out of scope of this change, so I want to work as another issue if it is
>needed.
>
Hi ,
I think we better do not call into WMI , when writing an hs_err file .
Best regards, M
12 matches
Mail list logo
