RFR: JDK-8297408: Consolidate code in runtime/ErrorHandling [v3]

[David Holmes]

On Fri, 25 Nov 2022 17:52:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> There is a lot of duplicate coding in runtime/ErrorHandling that could be cut down using the new HsErrFileUtils utilities added with [JDK-8296906](https://bugs.openjdk.org/browse/JDK-8296906).
>> 
>> This patch mainly cuts away duplicate coding. Very minor functional changes:
>> - All tests will now use try-with-resources when opening hs-err files
>> - [TestCrashOnOutOfMemoryError.java](https://github.com/openjdk/jdk/pull/11283/files#diff-7560f2e2700932e015563716b3b0880495922c4c5731ddadba3b33bd937358bd) now checks for at least one matching line in the hs-err file - before, it basically just scanned for the END marker, which seemed pointless
>> - [test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java](https://github.com/openjdk/jdk/pull/11283/files#diff-c04dd18d5a29a42e3a9a008c0b917663a7617c8c9a0d6e9efe8755773260ea95) : heaved Pattern construction out of loop
>> - [test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java](https://github.com/openjdk/jdk/pull/11283/files#diff-086956c42403a16043a111b0582736ac21ce0522dba866f5f9bc3fdb16037a0c) : I tried to preserve the debug output that was painstakingly added by @dcubed-ojdk apart from one change: I now printe the hs-err file as part of the scanning process. This works fine since in case of success, it will only be parsed as far as all patterns are matched, which happens after five-ish lines. Only if none are found, we scan and therefore print the whole hs-err file. So the old behavior is preserved in spirit.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights and comments

Our CI passed tiers 1-3

-------------

PR: https://git.openjdk.org/jdk/pull/11283