RFR: 8294402: Add diagnostic logging to VMProps.checkDockerSupport [v4]
Daniel D. Daugherty
dcubed at openjdk.org
Wed Feb 1 23:21:25 UTC 2023
On Wed, 1 Feb 2023 22:59:47 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:
>> test/jtreg-ext/requires/VMProps.java line 519:
>>
>>> 517: private String redirectOutputToLogFile(String msg, ProcessBuilder pb, String fileNameBase) {
>>> 518: if (!Boolean.getBoolean("jtreg.log.vmprops")) {
>>> 519: return "";
>>
>> I think having to explicitly enable this somewhat defeats the purpose of using it for diagnostics. If we get an unexpected failure we will have to reproduce it with logging enabled to see what went wrong.
>
> If I remove this conditional guard then we will see extra output at the beginning of test run which might be undesirable. For instance:
>
> jtreg -v1 -conc:4 -Djtreg.log.vmprops=true open/test/hotspot/jtreg/containers/docker/
>
> VMProps: Entering call()
> VMProps: Entering dockerSupport()
> VMProps: dockerSupport(): platform check: isSupported = false
> VMProps: dockerSupport(): returning isSupported = false
> VMProps: Leaving call()
> Test results: no tests selected
>
>
> I am not sure what is the best thing to do here, so I stayed on a "safe" side and added this conditional guard. The model in my mind is that such logging is normally off but can be turned on in case the issue is suspected. However if you believe it should be always on I can remove the guard.
The failure happens so rarely I think you need to leave the option on in order to get
any useful information about this issue when it occurs in Mach5. If a sighting happens
in Mach5, I don't think rerunning another task on the same machine will necessarily
fail so you need to get the information from the failures that do occur.
-------------
PR: https://git.openjdk.org/jdk/pull/12239
More information about the hotspot-dev
mailing list