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 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.
Okay use another issue to do deferred initialization of detailed version
info that may not be used. I'm not sure exactly what that covers.
Concurrent initialization may be an issue to consider.
Thanks,
David
P.S I have a long weekend coming up.
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
