8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old

[earthling-amzn]

When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.

Background

When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers after the thread local SATB buffers were completed. After this change, such pointers are filtered out before the buffers are completed. This is more inline with the natural way of things.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27983/head:pull/27983
$ git checkout pull/27983

Update a local copy of the PR:
$ git checkout pull/27983
$ git pull https://git.openjdk.org/jdk.git pull/27983/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27983

View PR using the GUI difftool:
$ git pr show -t 27983

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27983.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back wkemper! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@earthling-amzn The following labels will be automatically applied to this pull request:

• hotspot-gc
• shenandoah

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (ec58b72f)

[kdnilsen]

This is a great simplification. Do we have any performance numbers, especially for reduction in p99.999 and p100 latencies with certain Extremem workloads, which I believe to be related to safepoint flushing of satb buffers?

[kdnilsen]

Might be worth mentioning that there may be some additional analysis and code required when we use the forwarding table to recycle cset regions during evacuation and/or updating. If one of these regions becomes old before the SATB buffers have been flushed, then a young cset pointer that lingers in a SATB buffer will "all of a sudden" look like a valid old pointer and will not be purged from the SATB buffer. When we subsequently scan the "object" referenced by this obsolete pointer, we are likely to find "garbage memory", possibly resulting in a crash.

I am thinking that an initial fix might be to do this flushing at init-update-refs instead of at final update refs, and to not recycle cset regions until evacuation is all done. Is there a different handshake there that we might piggyback on?

[earthling-amzn]

Hmm, that's a good point about recycling regions concurrently. I don't think we can flush before init-update-refs because forwarded pointers still exist and the SATB barrier doesn't try to resolve them. That is to say, "bad" pointers can be created throughout the update-refs phase.

Even in the (hypothetical) scenario with a forwarding table, a region would only become old through an in-place-promotion (in which case, it will never have been recycled) or we will be doing a mixed evacuation. If we are running a mixed evacuation, we will already have finished marking old.

[earthling-amzn]

I have results from an earlier version of this PR that flushed the buffers during init-mark. That version showed a consistent 3% improvement on critical and max jops. They also showed a reduction in p99.999 latency for some of the extremem measurements. I will retest with this version.