On 1/8/14 6:48 PM, Chris Hegarty wrote:
The cleanup looks fine to me, and the retaining of strong refs to the loggers.
Is the weak ref guaranteed to be cleared at some point?
Hi Chris,
I added a counter to the loop just to make sure
it won't loop infinitely. Note that the goal of the loop is
just to make 8031068 more likely to happen - if you add
-server -Xcomp to the VM command line and add
createdLoggers.clear() just before entering the loop
(which 'unfixes' the test) then the test fails immediately
with the same error than that revealed by 8031068.
<http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.01/>
best regards,
-- daniel
-Chris
On 8 Jan 2014, at 17:34, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
Hi,
Please find below a patch for a test bug:
8031068: java/util/logging/ParentLoggersTest.java:
checkLoggers: getLoggerNames() returned unexpected loggers
https://bugs.openjdk.java.net/browse/JDK-8031068
<http://cr.openjdk.java.net/~dfuchs/webrev_8031068-jdk9/webrev.00/>
As usual - the issue is that the test creates loggers without
keeping any strong reference - thus allowing for the possibility
that they will be garbage collected too soon.
I managed to reproduce systematically by adding a call to
System.gc() between the creation of the two loggers - and
passing -Xcomp -server to the VM.
With the fix the test no longer fails in that configuration.
best regards,
-- daniel
