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
