RFR(S): 7041440: G1: assert(obj->is_oop_or_null(true )) failed: Error #

[John Cuthbertson]

Hi Everyone,

I'm all set thanks to Tony and Igor.

JohnC

On 05/16/11 16:09, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers to review the fix for this CR - the 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7041440/webrev.0
>
> The issue here was that, during a marking cycle, we had a heap region 
> (R) that was allocated as a young GC alloc region during an evacuation 
> pause (pause A). In the same pause it was retired and its NTAMS value 
> was set to top(). It was also added to the collection set for the next 
> evacuation pause (pause B).
>
> After pause A, a concurrent marking task claimed region R and started 
> to scan it. Because of the test configuration the concurrent marking 
> did not run for very long before pause B.
>
> During pause B, region R was evacuated and added to the free list. The 
> concurrent mark task which had earlier claimed R for scanning was 
> still holding on to it.
>
> During a subsequent evacuation pause region R was allocated as an old 
> GC alloc region. When R was retired its NTAMS was set to top().
>
> During the subsequent concurrent marking, the region fields in the 
> concurrent marking task were updated resulting in the value of the 
> task local finger being set to R's NTAMS value - effectively skipping 
> scanning the objects copied into R when it was  an old GC alloc region.
>
> The solution is, during an evacuation pause, to scan the local fingers 
> of the concurrent marking tasks. If we find local finger that points 
> into the collection set then we need to have the concurrent mark task 
> give up that claimed region as the values in the region fields will 
> become stale. This will cause the concurrent mark task to claim a new 
> region when marking restarts after the pause.
>
> Testing: the original failing test case; gc test suite with a low 
> marking threshold. A jprt test job is in the queue.
>
> Thanks,
>
> JohnC