On Fri, 14 Oct 2022 18:37:03 GMT, Chris Plummer <[email protected]> wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading exception.
>>
>> waitAppReady() is really waitAppReadyOrCrashed(), and should not timeout
>> immediately after the 1 second sleep, or we lose a second of our timeout
>> value (not critical with a long timeout, but seems more honest).
>>
>> Show how long we waited when startup/crashing times out.
>>
>> Show how long a good startup takes, so we have a basic for comparison when
>> it fails.
>>
>> Show if there are hs_err/core/mdmp files in the working directory after
>> startup/crash attempt.
>>
>> Also, in open/test/lib/jdk/test/lib/util/CoreUtils.java:
>>
>> "Move core file" often seems unnecessary, core/mdmp usually being created in
>> the current directory. But getCoreFileLocation() performs Files.move() which
>> takes enough time to not be a no-op.
>
> test/lib/jdk/test/lib/apps/LingeredApp.java line 480:
>
>> 478: FilenameFilter filter = (dir, file) ->
>> (file.startsWith("hs_err_pid") || file.startsWith("core") ||
>> file.endsWith("mdmp"));
>> 479: for (File f : new File(".").listFiles(filter)) {
>> 480: System.out.println(f);
>
> Printing the size can be useful for core files.
Yes can add that. It could be useful as occasionally we wonder if a core/mdmp
is slow to write. A file size at this point might be useful to compare with a
file size viewed later.
-------------
PR: https://git.openjdk.org/jdk/pull/10613
