RFR: java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java failing again

[Daniel Fuchs]

On 12/19/13 5:39 PM, Mandy Chung wrote:
>
> On 12/19/2013 3:04 AM, Daniel Fuchs wrote:
>> On 12/18/13 9:35 PM, Mandy Chung wrote:
>>>
>>> On 12/17/2013 3:57 AM, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> Please find below a fix for what I believe is a test bug.
>>>> I plan to push this in JDK 9 dev.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8030187
>>>>
>>>> This seems to be a very intermittent failure.
>>>> It looks as if a logger held in a local variable can be
>>>> arbitrarily garbage collected if that variable is no longer
>>>> used.
>>>> To prevent arbitrary garbage collection of such loggers, the fix
>>>> makes sure to use the variable again at the end of the test.
>>>>
>>>
>>> Looks like running the test in -Xcomp and also with jtreg creates
>>> pressure to the young gen and more object allocation failure and so
>>> unreachable objects get collected in the middle of a small method body
>>> (like in this case).
>>>
>>> You added code to reference the local variables referencing the
>>> loggers.  Would it be simpler to have this test  just to hold a strong
>>> reference to the logger?
>>
>> Hmmm. I don't think it would be simpler. I could have added an
>> array list of loggers and cleared that at the end of the test.
>> It would just have been another way of making sure that the
>> loggers weren't gc'ed.
>
> Are you concerned that a static/instance field holding the loggers gets
> GC'ed if not referenced before the test method returns?   They should be
> only collected when the class/instance becomes unreachable and it
> shouldn't be an issue (as do in other tests).

Yes - that was part of my concern. Reusing the variable at the end
of the test makes it obviously visible that it can't be gc'ed before
that.

> I'm fine with what you have.

OK thanks Mandy, I think I will push what I have then.
This is what I have tested - by running it for several hours in a
loop :-)

-- daniel

>
> Mandy