Garbage collection race condition before final checks

[Gary Adams]

On 11/9/11 4:08 AM, Alan Bateman wrote:
> On 08/11/2011 15:35, Gary Adams wrote:
>>  Here's another intermittent bug that is attributed
>> to the garbage collection of the loggers before the
>> final static check can be applied in the test.
>>
>> CR#7067691 : 
>> java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java 
>> failing intermittently
> I agree with Mandy that it would be great to do a quick audit of the 
> other logging (and PlatformLoggingMXBean) tests to see if we have 
> similar issues. I should explain that one reason why these test 
> failures may not have been observed in the past is because most people 
> ran jtreg in its default mode (called othervm mode, where each tests 
> runs in its own VM). Nowadays we run the tests via the make file or 
> use jtreg -agentvm so that tests are running sequentially in an agent 
> VM. Not all areas can run in agent VM mode yet but for the areas that 
> do then we get a good speed up as the startup cost is eliminated and 
> also it's possible to have a pool of agent VMs to make use of all 
> cores when doing test runs (-agentvm -concurrency:auto for example). 
> However agent VM makes things less predictable and for these tests it 
> means that the GC will be unpredictable which is why this test was 
> failing only very intermittently.
>
> Anyway, the changes look fine to me. I agree with Mandy that many 
> logger1 and logger2 could be instance variables. I would suggest 
> "proxy" or something more readable rather than "testp" for the 
> LoggingMXBean proxy. I also agree with Mandy's comment about adding 
> the @bug.
>
> -Alan.

"proxy" was my first choice, but that was already used for another local 
variable.
The original variable was just "p", but that seemed unwise for a global 
variable name.

... lather & rinse