RFR: 8294993: LingeredApp test update

[Kevin Walls]

On Fri, 14 Oct 2022 18:31:24 GMT, Chris Plummer <cjplummer at openjdk.org> 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 274:
> 
>> 272:         while (true) {
>> 273:             // Make sure process didn't already exit:
>> 274:             // check this now, and immediately after sleeping for spinDelay each loop.
> 
> I don't see how this reordering of the code makes any difference.

My thinking was that we check for exceeding timeout at the start of the loop, so if we do loop, we have just slept for spinDelay, and not checked the conditions for successful exit of the loop.  So we lose 1 second of timeout.
Now I see my error is that I should move the timeTaken check further down, after we check the lock file, so we do all success checking, then timeout checking, then sleep for spinDelay.

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

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