On Fri, 14 Oct 2022 18:31:24 GMT, Chris Plummer <cjplum...@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
