Garbage collection race condition before final checks
gary.adams at oracle.com
Wed Nov 9 10:55:00 UTC 2011
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 :
>> 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.
"proxy" was my first choice, but that was already used for another local
The original variable was just "p", but that seemed unwise for a global
... lather & rinse
More information about the core-libs-dev