RFR(S): 7041440: G1: assert(obj->is_oop_or_null(true )) failed: Error #
john.cuthbertson at oracle.com
Tue May 17 00:17:02 UTC 2011
I'm all set thanks to Tony and Igor.
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:
> 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.
More information about the hotspot-gc-dev