RFR (M): 8087198: G1 card refinement: batching, sorting
manc at google.com
Wed Nov 20 02:26:23 UTC 2019
Thanks! I have addressed all comments:
Tested on submit repo and stress tested locally with and without the
Removing DEBUG_ONLY KVHashtable fixed the Windows build errors on submit
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
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
the code a bit because of hot card cache replacing buffer's element
I also changed G1RemSet::clean_card_before_refine() to take a "CardValue**"
parameter instead of "CardValue*&" to make it more obvious that it can
the card pointer.
More information about the hotspot-gc-dev