CRR: 7034139: G1: assert(Thread::current()->is_ConcurrentGC_thread()) failed: only a conc GC thread can call this (S)

John Cuthbertson john.cuthbertson at oracle.com
Wed Apr 20 21:04:25 UTC 2011


Hi Tony,

I should get to this later this afternoon. I want to kick off testing of 
the fix for 7037756 first.

JohnC

On 04/20/11 12:56, Tony Printezis wrote:
> Hi all,
>
> I'd still like a couple of code reviews for this. Here's the latest 
> version (I only rephrased a couple of comments, so if you're looking 
> at the earlier version already you can ignore this one):
>
> http://cr.openjdk.java.net/~tonyp/7034139/webrev.1/
>
> Tony
>
> Tony Printezis wrote:
>> Hi,
>>
>> Could I get a couple of people to look at this? (I'd like to push 
>> this this week if possible)
>>
>> http://cr.openjdk.java.net/~tonyp/7034139/webrev.0/
>>
>> The actual fix is reasonably small (leave / join the 
>> SuspendibleThreadSet only if we are in concurrent mode). Most of the 
>> changes are new infrastructure to cause a fixed number of overflows 
>> during marking (in non-product builds of course) to stress the 
>> overflow code. This was the only way I could reliably reproduce the 
>> failure. This did uncover a couple of extra issues which I also fixed:
>>
>> - If we overflow during remark we should not actually deal with it 
>> during remark but we should abort the remark pause and restart a 
>> concurrent mark phase. For some reason we were not doing that. I 
>> fixed that (for this I had to ensure that the overflow flag is not 
>> cleared when we exit the do_marking_step() method).
>> - Because we were clearing the overflow, it was also possible that 
>> the workers would deadlock (for that to happen a worker had to finish 
>> handling one overflow and immediately raise another one, so it was 
>> highly unlikely to occur in prcatice; good to find it and eliminate 
>> it though).
>>
>> I've already tested it, I'll run more tests overnight.
>>
>> Tony




More information about the hotspot-gc-dev mailing list