RFR: 8246926: Clean up newlines and whitespaces in hs_err files

[David Holmes]

Hi Stefan,

I think the new file looks better but I am worried about the disruption 
this may cause to existing scraping tools that may be in use. The SAP 
folk seem to care most about the content and layout in this area so if 
they are okay with it then I'm okay with it.

Thanks,
David
-----

On 9/06/2020 10:49 pm, Stefan Karlsson wrote:
> One small update. I'd like to add a new line between the heap printing 
> and G1's heap region printing:
>   https://cr.openjdk.java.net/~stefank/8246926/webrev.02.delta/
>   https://cr.openjdk.java.net/~stefank/8246926/webrev.02
> 
> This now prints:
> 
> Heap:
>   garbage-first heap   total 2064384K, used 0K [0x0000000082000000, 
> 0x0000000800000000)
>    region size 16384K, 0 young (0K), 0 survivors (0K)
>   Metaspace       used 4K, capacity 4480K, committed 4480K, reserved 
> 1056768K
>    class space    used 4K, capacity 384K, committed 384K, reserved 1048576K
> 
> Heap Regions: E=young(eden), S=young(survivor), O=old, 
> HS=humongous(starts), HC=humongous(continues), CS=collection set, 
> F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start 
> (previous, next)
> |   0|0x0000000082000000, 0x0000000082000000, 0x0000000083000000| 0%| 
> F|  |TAMS 0x0000000082000000, 0x0000000082000000| Untracked
> |   1|0x0000000083000000, 0x0000000083000000, 0x0000000084000000| 0%| 
> F|  |TAMS 0x0000000083000000, 0x0000000083000000| Untracked
> 
> Instead of:
> 
> Heap:
>   garbage-first heap   total 2064384K, used 0K [0x0000000082000000, 
> 0x0000000800000000)
>    region size 16384K, 0 young (0K), 0 survivors (0K)
>   Metaspace       used 4K, capacity 4480K, committed 4480K, reserved 
> 1056768K
>    class space    used 4K, capacity 384K, committed 384K, reserved 1048576K
> Heap Regions: E=young(eden), S=young(survivor), O=old, 
> HS=humongous(starts), HC=humongous(continues), CS=collection set, 
> F=free, OA=open archive, CA=closed archive, TAMS=top-at-mark-start 
> (previous, next)
> |   0|0x0000000082000000, 0x0000000082000000, 0x0000000083000000| 0%| 
> F|  |TAMS 0x0000000082000000, 0x0000000082000000| Untracked
> |   1|0x0000000083000000, 0x0000000083000000, 0x0000000084000000| 0%| 
> F|  |TAMS 0x0000000083000000, 0x0000000083000000| Untracked
> 
> Thanks,
> StefanK
> 
> On 2020-06-09 12:17, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to clean up newlines and whitespaces in our 
>> hs_err files.
>>
>>  https://cr.openjdk.java.net/~stefank/8246926/webrev.01/
>>  https://bugs.openjdk.java.net/browse/JDK-8246926
>>
>> I've uploaded before and after hs_err files here:
>>  https://cr.openjdk.java.net/~stefank/8246926/webrev.01/hs_err_pid146249.before.log 
>>
>>  https://cr.openjdk.java.net/~stefank/8246926/webrev.01/hs_err_pid196998.after.log 
>>
>>
>> Main cleanups:
>> - Numerous one-liners where written as two lines:
>>
>> Old
>> ===
>> Online cpus:
>> 0-31
>> Offline cpus:
>>
>> cache level:
>> 1
>> cache type:
>> Data
>> cache size:
>> 32K
>> cache coherency line size:
>> 64
>> <... many more ...>
>>
>> New
>> ===
>> Online cpus: 0-31
>> Offline cpus:
>> cache level: 1
>> cache type: Data
>> cache size: 32K
>> cache coherency line size: 64
>>
>>
>> - Many lines missed a space after colon:
>>
>> Old
>> ===
>> VM state:not at safepoint (not fully initialized)
>>
>> New
>> ===
>> VM state: not at safepoint (not fully initialized)
>>
>>
>> - Newline after OS
>>
>> The code looked for various files (on Linux) and dumped their 
>> contents. The first line ended up on the OS: line, but the rest ended 
>> afterwards
>>
>> Example from Linux:
>> OS:DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=20.04
>> DISTRIB_CODENAME=focal
>> DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
>> uname:Linux
>>
>> Example from macOS:
>> OS:uname:Darwin
>>
>> I couldn't find a quick and clean fix for this, so I simply opted to 
>> add a newline after "OS:".
>>
>>
>> - There are a number of cr() calls (or ”\n" prints) that are used to 
>> add a complete blank line between sections. I moved a few of those out 
>> of the lower-level print functions, so that the caller could decide if 
>> there's a need for extra newlines.
>>
>> Thanks,
>> StefanK
>