RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code

[Albert Mingkun Yang]

On Mon, 27 Jun 2022 10:03:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Then why not just card-align addr and always use the fast path code?
>
> @kimbarrett: The `block_start` method returns the first object reaching into `addr`; if we aligned first, then the result would be the first object reaching into `aligned(addr)` which is different; the callers would need to advance forward not-requested objects then.
> Or maybe I'm missing something in your suggestion?

> I had something like that, but the "not observable" part was not that clear in my results

I added the following to `G1BlockOffsetTablePart::block_start` to see the cost.


  if (is_aligned(addr, BOTConstants::card_size())) {
    return q;
  }


Using `Scan Heap Roots (ms)` and `Scanned Cards` from `-Xlog:gc,gc+phases`, I can calculate #cards processed per ms. Surprisingly, I can observe some reduction (~2.7%) in this metric on my box.

Re Kim's suggestion, the model where `G1BlockOffsetTablePart::block_start` accepts only card-aligned addresses and the caller (`HeapRegion::block_start`) handles block-walking (heap parsing) makes more sense to me. (After all, "block size" is sth meaningful only inside `HeapRegion`.) Ofc, this can be dealt with in this PR or another.

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

PR: https://git.openjdk.org/jdk/pull/9059