JDK-8085865 : hs_err improvement: Printing /proc/cpuinfo makes too long hs_err files
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-04
  • Updated: 2015-09-10
  • Resolved: 2015-06-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b72Fixed
Related Reports
Relates :  
JDK-8026332 - hs_err improvement: Was the JVM run on a hypervisor
Relates :  
JDK-7165755 - OS Information much longer for linux than other platforms
Relates :  
JDK-8026324 - hs_err improvement: Add summary section to hs_err file
Description
On linux only, we print /proc/cpuinfo into the hs_err files which can be really long and redundant information for each processor and especially annoying when we have a lot of processors.  We already print this:

CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, tsc, tscinvbit, tscinv

Not sure why we need the /proc/cpuinfo printed out.  I don't know if anyone would ever use this specific (redundant) information to diagnose a problem.

os_aix.cpp has pd_print_cpu_info() which is called from os::print_cpu_info() which prints the exact same thing and should be removed.

It looks like this code was separated out of some other code that added this printing.
Comments
I think the line with model name is enough for x86. The other lines don't add information to the already printed line which all variants have. CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, tsc, tscinvbit, tscinv
11-06-2015
One of the reasons to request a summary is because some information in the hs_err_pid log files is too long and the hs_err file can get truncated by users when reporting a crash. This is motivation for not having long redundant information printed in the files.
11-06-2015
So only x86 is a problem it seems.
09-06-2015
After discussing with Christian, only model name gives you new information (you can look up the model name on the machine web site), eg: CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, tsc, tscinvbit, tscinv model name : Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz
08-06-2015
What from /proc/cpuinfo should be added to CPU info? CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, tsc, tscinvbit, tscinv /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz stepping : 9 microcode : 0x12 cpu MHz : 1600.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes 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 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 s sse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lah f_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6584.73 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
08-06-2015
We already have a bug to print if we are running on a hypervisor. The /proc/cpuinfo is too long and people append these to hs-err files. In Mattis's words: "If I never have to scroll past the CPU data again, I would be happy... should we remove it? I can't think of anyone who wants to see all the cores on a machine, but maybe it is interesting for some dev teams?" It isn't that interesting. I think it would be better to add some code to parse cpuinfo if there is something that someone finds interesting in this file that is additional to what we already print.
05-06-2015
Surely a RFE not a bug :) I agree that on large SMP systems the quantity of data from /proc/cpuinfo can be overwhelming and somewhat repetitive. However the information can be useful for spotting that you are running on an emulator or VM rather than bare hardware. Plus not all platforms have such detailed CPU feature strings. It's a pity there isn't a better way to ask for the CPU info on linux. We really don't want to try and parse the /proc/cpuinfo output - which is what we would need to do if we wanted to limit the number of processors for which info was shown.
05-06-2015