Fwd: Re: RFR 8151939: VM_Version_init() print buffer is too small

[Coleen Phillimore]

Thanks Max!

On 4/7/16 4:41 PM, Max Ockner wrote:
> It looks like you already have a second reviewer, but this looks good 
> to me.
> I am assuming that "-version" is the appropriate program to test with 
> in this case since the logging is closely related to the version.

A lot of the output comes out with java -version.  The other output 
would be unreliable to test.

Coleen

> Thanks,
> Max
>
> On 4/7/2016 1:56 PM, Coleen Phillimore wrote:
>>
>> Can one of you guys review this change?  It only needs a small r 
>> reviewer because Vladimir is capital R.
>>
>> thanks,
>> Coleen
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	Re: RFR 8151939: VM_Version_init() print buffer is too small
>> Date: 	Thu, 7 Apr 2016 11:07:21 -0400
>> From: 	Coleen Phillimore <coleen.phillimore at oracle.com>
>> To: 	hotspot-dev at openjdk.java.net
>>
>>
>>
>> On 4/6/16 4:17 PM, Vladimir Kozlov wrote:
>> > Should we use p2i() instead of (intprt_t) for polling and
>> > mem_serialize pages?
>>
>> Yes, this is better.  I fixed these and recompiled.
>> >
>> > os_windows.cpp - does ~Log destruct or will generate 'new line'? I am
>> > simple asking since I don't know.
>> No the log.debug() lines each have a new line (which makes the output
>> come out on multiple lines). The only way I know to make the output come
>> out in all one line is to use a logStream() which requires a
>> ResourceMark which is inconvenient in a lot of places in the os layer
>> code (may not have current thread).
>> >
>> > 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",
>>
>> The \n is unneeded, I missed this.  Thanks.
>> >
>> > Why new OsCpuLoggingTest.java test has SAP Copyright?
>>
>> Oops, I copied this from the SAP test. Thank you for noticing this!
>>
>> Coleen
>> >
>> > 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 athttp://cr.openjdk.java.net/~coleenp/8151939.02/webrev
>> >> bug linkhttps://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 athttp://cr.openjdk.java.net/~coleenp/8151939.01/webrev
>> >>> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8151939
>> >>>
>> >>> Tested in rbt and jprt.
>> >>>
>> >>> Thanks,
>> >>> Coleen
>> >>
>>
>>
>>
>