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: Windows 10 x64 (May 2020 Update)
* Java: jdk/jdk revision 60537
(Compiled by VS 2019 (16.7.0))
* without patch
TotalMilliseconds : 70.2124
TotalMilliseconds : 64.4465
TotalMilliseconds : 59.0854
TotalMilliseconds : 68.0255
TotalMilliseconds : 72.6467
average : 66.8833
* with webrev.01
TotalMilliseconds : 81.7185
TotalMilliseconds : 68.539
TotalMilliseconds : 85.7226
TotalMilliseconds : 72.6584
TotalMilliseconds : 75.6091
average : 76.84952
Overhead of WMI seems to be +10ms in this case.
Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this
were to go in as-is.
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.
Yasumasa
David
-----
Yasumasa
On 2020/08/13 0:05, Baesken, Matthias wrote:
I understand that if the process runs on Xen on other hypervisor (e.g. KVM),
information for Xen would be set between 0x40000100 and 0x40010000.
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 some more info on this it would
be better to judge if it is perfectly okay or concerning .
(I remember that I looked into it a couple of years ago , but decided not to use it in
early VM startup ; but have to confess this was just based on a "gut feeling",
No micro benchmarks )
Best regards, Matthias
