RFR [XS]: 8244196: adjust output in os_linux

[Baesken, Matthias]

Hi David , new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8244196.1/


>While I personally prefer things on one line and no blank lines I am 
>concerned that this make unnecessarily break scripts that try to mine 
>hs_err logs.

Yes that might  indeed be true .  I changed the output  back  and use print_cr   for the header output (so we continue to have separate lines for header and content).
I added " :"  as suggested.

Also  added some example output to the JBS issue  (however now the before/after is not that different any more ) .

Best regards, Matthias

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Dienstag, 5. Mai 2020 09:31
To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
Subject: Re: RFR [XS]: 8244196: adjust output in os_linux

On 4/05/2020 8:55 pm, Baesken, Matthias wrote:
> Hi David ,  the newlines were removed by me because when looking at the hs_err files it seemed to me, that we have too much of them.
> ( but of course this might be a matter of taste , and not so much of correctness )

Very much a matter of taste. :) Presently we print:

header1:
value1
<blank>
<blank>
header2:
value2
<blank>
<blank>

whereas you are now putting all that on one line and deleting empty lines:

header1:value1
header2:value2

While I personally prefer things on one line and no blank lines I am 
concerned that this make unnecessarily break scripts that try to mine 
hs_err logs.

Also you need as space after the : so this

static void _print_ascii_file_h(const char* header, const char* 
filename, outputStream* st) {
   st->print("%s", header);

should use "%s " (and arguably the : should be part of the format string 
rather than in the header itself).

> The output part looks like (from one of our Linux x86_64 machines)  this now :
> 
> /sys/kernel/mm/transparent_hugepage/enabled:[always] madvise never
> /sys/kernel/mm/transparent_hugepage/defrag (defrag/compaction efforts parameter):[always] madvise never
> 
> /proc/sys/kernel/threads-max (system-wide limit on the number of threads):1032335
> /proc/sys/vm/max_map_count (maximum number of memory map areas a process may have):2147483647
> /proc/sys/kernel/pid_max (system-wide limit on number of process identifiers):81920

Please add before/after examples t the bug report.

Thanks,
David