RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v9]

[Albert Mingkun Yang]

On Thu, 21 Sep 2023 09:49:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> So I found the cause for the regression with precise scanning of large arrays: it was the redundant queries of the start array.

Yes, `object_start` can be quite expensive when obj-start is far away.

> byte_for(align_up(first_obj_addr, _card_size_in_words))

I recall this triggers an assertion failure when the address after alignup is the end-of-heap.

> Basically you need a 2nd card table to collect the dirty marks, don't you?

I experimented with the aforementioned read-only card table idea a bit and here is the draft:
https://github.com/openjdk/jdk/compare/master...albertnetymk:jdk:pgc-precise-obj-arr?expand=1

Most are quite straightforward after creating a "shadow" card table; it also includes an optimization to avoid expensive calls to find object-start. The optimization is nicely isolated from the real work, so the code looks fairly readable, IMO.

I can't observe much perf diff running bms using the latest revision of this PR and shadow-card-table, except for `card_scan.java`. Additionally, the cost of calling `object_start` multiple times starts to
show up significantly when dirty cards are scarce. For example, `card_scan.java` + `static final int stride = 32 * 64;`:


## this PR

[0.002s][info][gc] Using Parallel
[1.338s][info][gc] GC(0) Pause Young (Allocation Failure) 1791M->1027M(2944M) 157.749ms
[1.593s][info][gc] GC(1) Pause Young (Allocation Failure) 1795M->1027M(2944M) 139.567ms

## shadow card table

[0.002s][info][gc] Using Parallel
[1.240s][info][gc] GC(0) Pause Young (Allocation Failure) 1791M->1027M(2944M) 25.763ms
[1.379s][info][gc] GC(1) Pause Young (Allocation Failure) 1795M->1027M(2944M) 24.372ms

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

PR Comment: https://git.openjdk.org/jdk/pull/14846#issuecomment-1733480484