Here's a description from the Evaluation field of 6578335 during the investigation
of which this problem was first discovered:-

There was a third bug found which relates to the handling of
"second ring overflow" when using parallel concurrent marking
-- the overflow of the global overflow stack (which itself handles
the overflow from the local work queues). The intention was
that this second ring overflow should use the "restart mechanism"
to restart marking from the least overflown address.
That mechanism was not completely extended to the parallel
concurrent marking case. The restart_addr was not pushed
all the way through to the parallel concurrent marking task that controls
the parallel concurrent marking. Because of the partial
change to the state of the parallel concurrent marking task,
we can and often will end up missing the scan of some of the
addresses at the higher extremes of the CMS-collected
generations. Because second-ring overflow is a very rare
event in practice, this appears to have not been detected
before (or at least not until the first two bugs mentioned
above were moved out of our way).

The obvious workaround is to switch off parallel concurrent
marking via -XX:-CMSConcurrentMTEnabled.