RFR 8151939: VM_Version_init() print buffer is too small

[Vladimir Kozlov]

Should we use p2i() instead of (intprt_t) for polling and mem_serialize 
pages?

os_windows.cpp - does ~Log destruct or will generate 'new line'?  I am 
simple asking since I don't know.

os_linux_x86.cpp - do we need \n at the end of logging line?:
+  log_info(os)("OS version is %d.%d, which %s support SSE/SSE2\n",

Why new OsCpuLoggingTest.java test has SAP Copyright?

Thanks,
Vladimir

On 4/6/16 11:39 AM, Coleen Phillimore wrote:
>
> I removed ancient logging from the signal handler and left a corrected
> comment instead.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8151939.02/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8151939
>
> Thanks,
> Coleen
>
> On 4/5/16 7:37 PM, Coleen Phillimore wrote:
>> Summary: Increase buffer size, use logging to print out version and os
>> information
>>
>> This replaces several -XX:+PrintMiscellaneous -XX:+Verbose to -Xlog:os
>> or -Xlog:os+cpu.  Most use info level logging because it's only
>> printed once at the beginning, except where printing is in the signal
>> handler, which uses debug level.  Also, errors in setup use info level
>> (not warning) since they never printed the warnings before without
>> PrintMiscellaneous and Verbose.
>>
>> busaa027% java -Xlog:os -version
>> [0.008s][info][os] SafePoint Polling address: 0x00007fde1d37f000
>> [0.008s][info][os] Memory Serialize Page address: 0x00007fde1d37d000
>> [0.009s][info][os] HotSpot is running with glibc 2.12, NPTL 2.12
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build
>> 9-internal+0-2016-04-05-170806.cphillim.jdk9.vm-version)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build
>> 9-internal+0-2016-04-05-170806.cphillim.jdk9.vm-version-coleen, mixed
>> mode)
>>
>> busaa027% java -Xlog:os,os+cpu -version
>> [0.008s][info][os] SafePoint Polling address: 0x00007f49c021f000
>> [0.008s][info][os] Memory Serialize Page address: 0x00007f49c021d000
>> [0.009s][info][os] HotSpot is running with glibc 2.12, NPTL 2.12
>> [0.011s][info][os,cpu] Logical CPUs per core: 2
>> [0.011s][info][os,cpu] L1 data cache line size: 64
>> [0.011s][info][os,cpu] UseSSE=4  UseAVX=2  UseAES=1
>> MaxVectorSize=64Allocation prefetching: PREFETCHNTA at distance 192, 4
>> lines of 64 bytes
>> [0.011s][info][os,cpu] PrefetchCopyIntervalInBytes 576
>> [0.011s][info][os,cpu] PrefetchScanIntervalInBytes 576
>> [0.011s][info][os,cpu] PrefetchFieldsAhead 1
>> [0.011s][info][os,cpu] ContendedPaddingWidth 128
>> [0.011s][info][os,cpu] CPU:total 72 (18 cores per cpu, 2 threads per
>> core) family 6 model 63 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2,
>> sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms,
>> lzcnt, ht, tsc, tscinvbit, bmi1, bmi2
>> [0.011s][info][os,cpu] CPU Model and flags from /proc/cpuinfo:
>> [0.011s][info][os,cpu] model name    : Intel(R) Xeon(R) CPU E5-2699 v3
>> @ 2.30GHz
>> [0.011s][info][os,cpu] flags        : fpu vme de pse tsc msr pae mce
>> cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
>> sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc
>> arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf
>> eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma
>> cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt
>> tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb
>> xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
>> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
>> java version "9-internal"
>> Java(TM) SE Runtime Environment (fastdebug build
>> 9-internal+0-2016-04-05-170806.cphillim.jdk9.vm-version)
>> Java HotSpot(TM) 64-Bit Server VM (fastdebug build
>> 9-internal+0-2016-04-05-170806.cphillim.jdk9.vm-version-coleen, mixed
>> mode)
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8151939.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8151939
>>
>> Tested in rbt and jprt.
>>
>> Thanks,
>> Coleen
>