Garbage collection race condition before final checks

David Holmes david.holmes at oracle.com
Wed Nov 16 00:06:36 UTC 2011


Gary: Please do not start discussing other bugs in this thread - please 
keep them distinct.

Remi: please add any comments to the discussion threads on those other bugs.

Thanks
David

On 16/11/2011 12:30 AM, Rémi Forax wrote:
> On 11/15/2011 01:26 PM, Gary Adams wrote:
>> Added PlatformLoggingMXBeanTest to the 7067691 bug fix,
>> e.g. instance variables for Logger variables to prevent premature
>> weak reference collection.
>>
>> http://cr.openjdk.java.net/~gadams/7067691/
>
> Hi Garry,
>
>>
>> Fresh webrevs for the other work in progress bug fixes.
>>
>> http://cr.openjdk.java.net/~gadams/6731620/
>
> You can declare and initialize elapsed at the same place :
> final long elapsed = System.currentTimeMillis() - start;
> otherwise, it looks ok.
>
>> http://cr.openjdk.java.net/~gadams/6818464/
>
> if you want to have a variable changed in an inner class, the usual idiom
> is to use an array of one element.
>
> public static void main (String[] args) throws Exception {
> + final Thread[] tdThread = new Thread[1];
> Timer t = new Timer();
>
> // Start a mean event that kills the timer thread
> t.schedule(new TimerTask() {
> public void run() {
> + tdThread[0] = Thread.currentThread();
> throw new ThreadDeath();
> }
> }, 0);
>
> // Wait for mean event to do the deed and thread to die.
> try {
> + do {
> Thread.sleep(100);
> + } while(tdThread[0] == null);
> } catch(InterruptedException e) {
> }
> + tdThread[0].join();
>
> // Try to start another event
> try {
> // Timer thread is dead now
> t.schedule(new TimerTask() {
>
>
>
>> http://cr.openjdk.java.net/~gadams/6860309/
>
> This one is ok for me :)
>
>> http://cr.openjdk.java.net/~gadams/7084033/
>
> Thumb up for this one too !
>
> cheers,
> Rémi
>
>>
>> On 11/10/11 09:41 AM, Gary Adams wrote:
>>> On 11/ 8/11 11:13 PM, Mandy Chung wrote:
>>>>
>>>>
>>>> Thanks for picking up this bug and fixing this intermittent issue.
>>>> PlatformLoggingMXBeanTest.java in the same directory has the same
>>>> issue. It'd be good to fix that with the same CR. These tests were
>>>> copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't
>>>> looked in details but I wonder why the test/java/util/logging tests
>>>> don't have this intermittent issue and I suspect it holds a strong
>>>> reference.
>>>
>>> I attempted to break PlatformLoggingMXBeanTest.java with a generous
>>> application of
>>> GC calls, but I could not get it to fail in the same manner as the
>>> other test. It may be
>>> failing due to a different condition.
>>>
>>
>



More information about the core-libs-dev mailing list