RFR (XXL): 8213108: Improve work distribution during remembered set scan

[Thomas Schatzl]

Hi all,

On Mon, 2019-06-03 at 11:43 +0200, Thomas Schatzl wrote:
> Hi all,
> 
> On Fri, 2019-05-24 at 14:58 +0200, Thomas Schatzl wrote:
> > Hi all,
> > 
> >   can I have reviews for this change to the way we scan cards from
> > the various heap roots (remembered sets, log buffers, hcc) during
> > garbage collection to improve performance?
> > 
> > Instead of iterating over remembered sets of all regions in the
> > current collection set increment,
> 
> [...]
> 
>   let me retract this change for a bit.
> 
> While looking at another issue I found that the prediction code needs
> some updates, at least regarding the naming there.
> 

  there were some issues with determining the costs for scanning
remembered set cards and log buffer cards. This caused some differences
to old behavior with some application wrt to the sampling thread, more
often than necessary prematurely ending the mutator phase.

Two related notes:
- the change distributes scanning costs for remset and log buffer cards
according to number of cards from the respective heap root sources.
However log buffer cards are counted inexactly, i.e. may have
duplicates, so the total number of cards actually scanned may be less
than the cards in the log buffers. The changes handle this situation by
assigning all time to log buffer scan costs in this case, as it would
be kind of expensive to detect duplicates in the buffers.

- the hot card cache cards are ignored - first, we do not count them
yet at all, and they are very few anyway. Actually I remembered that
long ago I did some measurements about the effectiveness of the HCC (it
is also *very* small), and I remember that at least the current
implementation does not help at all in any of the applications I tried
that time.
I will file some issues to first, consider it in this calculation, and
second, investigate its removal. Its helper data structure takes quite
a bit of space after all.

Webrevs:
http://cr.openjdk.java.net/~tschatzl/8213108/webrev.0_to_1/ (diff)
http://cr.openjdk.java.net/~tschatzl/8213108/webrev.1/ (complete)
Testing:
hs-tier1-5, rerun of perf benchmarks with no differences to before,
some additional applications that showed abnormal sampling thread
behavior.

Thanks,
  Thomas