RFR: 8212630: jtreg/gc/logging/TestMetaSpaceLog.java failed with Agent timed out

[Leonid Mesnik]

Hi

I think that '@run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI' could be replaced with @run main/driver because
test spawns other process and don't use any options and WB.

Also I think you need to have several separate headers for each test instead of multiple runs. There is only one result per test (not for every run) and test is is skipped if any of GC is not supported. Additionally these tests might be guarded with require instead of throwing SkipException. So your tests is not going to be executed saying if ZGC is selected by jtreg CLI. Here is the example of fix which update test with different GCs. It contains a lot of examples of similar tests.
http://hg.openjdk.java.net/jdk/jdk/rev/9b8926bf85c1 <http://hg.openjdk.java.net/jdk/jdk/rev/9b8926bf85c1>

And in the case of new timeouts/other failures we will know exactly which GC was used right in the report.

Leonid

> On May 30, 2019, at 12:29 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to a test to attempt to eliminate very
> intermittent timeouts in Oracle's regression testing.  (Note that more
> recent failures don't involve agent timeouts, as the test has been
> modified to no longer use agent mode.)
> 
> The test currently consists of one process which launches child
> processes to test each of a set of GCs.  We suspect that approach may
> result in the single main process exceeding the normal timeout period
> when under high load or on a slow machine (or both).  If so, the
> situation will only get worse if more GCs are added to the current
> (incomplete) set.
> 
> We attempt to address this by instead having a separate main process
> for each tested GC, with the GC to test specified by a command line
> argument.
> 
> [It's possible there is some other underlying problem that has nothing  
> to do with the specific test, in which case this change might actually
> result in more frequent timeouts of this test.  If that happens, we'll
> deal with it as a new problem, with more information than we have now,
> possibly including extra timing information from JDK-8219149.]
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8212630
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8212630/open.00/
> 
> Testing:
> A few dozen local executions of the test.  That's not enough and
> probably not in a configuration to encounter the problem -- failures
> have been occurring on the order of 0.5% of the time under high load.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190530/05b34b9c/attachment.htm>