RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v2]

[Yude Lin]

> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
> 
> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.

Yude Lin has updated the pull request incrementally with two additional commits since the last revision:

 - 8272083: G1: Concurrently fix block offset table
 - Revert "8272083: G1: Record iterated range for BOT performance during card scan."
   
   This reverts commit 7f4bb6e459880bd9fcf132099280b22e022baccb.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5039/files
  - new: https://git.openjdk.java.net/jdk/pull/5039/files/7f4bb6e4..07a8b9e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=00-01

  Stats: 1273 lines in 24 files changed: 1225 ins; 35 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5039/head:pull/5039

PR: https://git.openjdk.java.net/jdk/pull/5039