RFR (M): 8087198: G1 card refinement: batching, sorting

[Man Cao]

Hi all,

Thanks! I have addressed all comments:
Full: http://cr.openjdk.java.net/~manc/8087198/webrev.02/
Incremental: http://cr.openjdk.java.net/~manc/8087198/webrev.01-02.inc/

Tested on submit repo and stress tested locally with and without the
KVHashtable.
Removing DEBUG_ONLY KVHashtable fixed the Windows build errors on submit
repo.

Some responses below.

The assert looks safe (and the code valid) because in case of a
> safepoint (e.g. remark) the card is re-evaluated with the potentially
> new top anyway.
> I.e. there can not be a safepoint with potential removal of the
> humongous regions between cleaning and actual refining. Other old gen
> region's top never change.

 I also added a comment that cleaning and refining of a card cannot span
across safepoint.

Though it will work and uses two pointers, that isn't the two-finger
> compaction algorithm I was suggesting.  I intended something based on
> the algorithm attributed to Edwards (and used by us for SATB buffer
> filtering; see SATBMarkQueue::apply_filter, which might even be usable
> as-is with a suitable filter_out function); see Jones & Lins GC book,
> section 5.3; or Jones et al GC Handbook, section 3.1; or web search
> for "edwards two-finger compaction".
> It has the benefit over the proposed algorithm of doing no more and
> possibly significantly fewer element moves.  It doesn't maintain the
> order of the elements, but we're doing a sort after the compaction.

Thanks for the clarification. Now it uses this algorithm, but I needed to
rewrite
the code a bit because of hot card cache replacing buffer's element
in-place.

I also changed G1RemSet::clean_card_before_refine() to take a "CardValue**"
parameter instead of "CardValue*&" to make it more obvious that it can
modify
the card pointer.

-Man