JDK 9 RFR for 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281

[Daniel Fuchs]

On 1/20/14 7:17 PM, Mandy Chung wrote:
> On 1/17/2014 6:51 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a webrev for:
>>
>> 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281
>> https://bugs.openjdk.java.net/browse/JDK-8031980
>>
>> <http://cr.openjdk.java.net/~dfuchs/webrev_8031980/webrev.00/>
>
> The new test looks reasonable.    "foo.bar5.level = INFO" is commented
> out in deadlock.conf.properties.  Is this intentional?

Yes - I still wanted to have a case where a logger wouldn't
have a parent in the configuration file - just in case
(although that should already be tested by the 'old' test).

> The test runs in
> the same VM first without security manager and then with security
> manager.   The loggers have been created and may/may not be GC'ed.  I
> wonder if it's worth breaking them into two separate runs so that each
> run starts with no logger.

hmm. good point. I don't think it really needs to though.
Most of the time the deadlock will happen with "with no security", but
sometimes you have to wait for the "with security" before it does
happen. And sometime you have to rerun the test - but that is rare.

IMHO a bit of randomness is not bad for that kind of test.

>     Have you also tried running this with
> -Xcomp and see if any intermittent failure due to GC?   It looks fine
> when reviewing the test but better to verify it.

No - haven't tried yet. Will do. However I saw it fail with errors
indicating that loggers which should not have been gc'ed had been
gc'ed when I ran it on a platform that didn't have JDK-8029281,
which means that it's also a good test for the changes in
LoggerWeakRef.dispose() from JDK-8029281.

May I push after verifying that it doesn't fail with -Xcomp?

best regards,

-- daniel

>
> Mandy