RFR: 8069367: assert(_nextMarkBitMap->isMarked((HeapWord*) obj)) failed

[Kim Barrett]

On Apr 14, 2015, at 5:05 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
> Do yo mean that this is the paragraph that explains the liveness issue?
> 
> 3436     // In order to maintain SATB invariants, during concurrent mark
> 3437     // we should only nominate an object containing references if it
> 3438     // was allocated after the start of marking, as such an object
> 3439     // doesn't need to have its references scanned.
> 
> I interpret that as that we should not nominate the objects that we actually then go ahead and nominate anyway. And that the comment starting at line 3445 just says that we do this. I don't understand this comment (lines 3436-3439) as explaining that the main problem is that reclaimable humongous objects can be the only old objects that keep an object graph alive. Can we reword this somehow? I've read the full comment a few times and to me it still sounds like the main problem is the remembered sets, which I don't really agree with. I agree that it is a problem, but I don't think it is the main problem.

I think I see what the problem is.  Because of code rearrangement (and
deletion), all of this text is now in one "block" and it is less clear
how the pieces relate.

How about if the first two paragraphs were changed to something like
this:

----------

Candidate selection must satisfy the following constraints while
concurrent marking is in progress:

* In order to maintain SATB invariants, an object must not be
reclaimed if it was allocated before the start of marking and has not
had its references scanned.  Such an object must have its references
(including type metadata) scanned to ensure no live objects are missed
by the marking process.  Objects allocated after the start of
concurrent marking don't need to be scanned.

* An object must not be reclaimed if it is on the concurrent mark
stack.  Objects allocated after the start of concurrent marking are
never pushed on the mark stack.

Nominating only objects allocated after the start of concurrent
marking is sufficient to meet both constraints.  This will miss some
objects that satisfy the constraints, but the marking data structures
don't support efficiently performing the needed additional tests.

----------

That makes clear what the requirements are and how we meet them.  Then
the later paragraphs can be seen as further commentary on those
requirements.  The (old) third paragraph, about remembered sets, is an
additional limitation, which we might be able to lift someday.  And
the (old) fourth paragraph is a special case where we violate the
requirements and how we get away with doing so.

It's a lot of commentary, especially about things we don't presently
do, but this seems like the right place for the information.

Does that help?