RFR: 8208278: [mlvm] Deadlocked threads are not always detected

[Igor Ignatyev]

Hi David,

Overall looks reasonable. I have a couple of comments:
 - this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd be better to make changes in .jmpp file and regenerate .java
 - near L#18218, you changed for-loop to throw an exception as soon as we get 1st locked thread, this reduces amount of diagnostic information we would get in such failure scenarios, so I prefer checking _testFailed (or other bool) after the loop.
> +        // Sanity check that all the locks are available.
> +        for (int i = 0; i < THREAD_NUM; i++ ) {
> +            if (_locks[i].isLocked()) {
>                  Env.getLog().complain("Lock " + i + " is still locked!");
> -                _testFailed = true;
> +                throw new Exception("Some locks are still locked");
>              }
>          }
>  
> -        if ( _testFailed )
> -            throw new Exception("Some locks are still locked");

Thanks,
-- Igor

> On Feb 22, 2019, at 5:13 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8208278
> 
> The test was failing to find the expected deadlocks on OS X but it turns out that the test was simply racy and the race always lost on OS X. With logging enabled the test started failing on different platforms and in different ways.
> 
> The main logic of the test is restructured so that we don't assume things will happen within a certain time but instead we loop (or block) until they do and rely on the overall test timeout to detect there may be a problem.
> 
> Thanks,
> David
> 
>