8253971: ZGC: Flush mark stacks after processing concurrent roots

[pliden]

I looked into why almost all mark cycles see non-zero "mark completions". In other words, we almost always have some amount of mark work left to handle in the mark end pause. It turns out that worker threads don't flush their mark stacks in ZMarkConcurrentRootsTask::work(), which means they can hide work (in their thread local mark stacks) until those stacks are finally flushed out in ZMark::try_end(). The reason work can be hidden is that the set of worker threads executing ZMarkConcurrentRootsTask is not necessarily the same set of worker threads executing ZMarkTask. As a result, the mark end pause often becomes longer than it otherwise would have.

After fixing this, I did some tests with Dacapo, which shows the following improvement:

Before: Mark End Pause (avg/max): 0.391 / 1.142 ms
After: Mark End Pause (avg/max): 0.130 / 0.294 ms

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8253971: ZGC: Flush mark stacks after processing concurrent roots

Reviewers

• Albert Mingkun Yang (@albertnetymk - Author)
• Erik Österlund (@fisk - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/495/head:pull/495
$ git checkout pull/495

[bridgekeeper]

👋 Welcome back pliden! 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]

@pliden The following label will be automatically applied to this pull request:

• hotspot-gc

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

[mlbridge]

Webrevs

• 00: Full (1dd5cb7)

[albertnetymk]

I wonder if it makes sense to unify this PR with the same logic in ZMarkRootsTask to a function, sth like PostRootsScan. Additionally, such flushing is only needed if ParallelGCThreads != ConcGCThreads, right?

[pliden]

@albertnetymk Yes, the problem stems from ZWorkers::nconcurrent() potentially being less than ZWorkers::nworkers().

[albertnetymk]

Thanks for the explanation. I am curious if it's worth the trouble to make the flush conditional.

[fisk]

Looks good. We might also want to poke out mark stacks on the VM thread when we handshake threads, using a concurrent VM operation. But maybe that is a problem for another day.

[openjdk]

@pliden This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for more details.

After integration, the commit message for the final commit will be:

8253971: ZGC: Flush mark stacks after processing concurrent roots

Reviewed-by: ayang, eosterlund

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 5 new commits pushed to the master branch:

• 9604ee8: 8248238: Implementation: JEP 388: Windows AArch64 Support
• 1c2754b: 8253269: The CheckCommonColors test should provide more info on failure
• d296708: 8253606: Need to add missed constructor to the SwingEventMonitor
• 5810238: 8253945: Missed default constructor for StreamPrintServiceFactory.java
• 123e786: 8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[pliden]

I am curious if it's worth the trouble to make the flush conditional.

I don't think we need to special-case the flushing. This condition is almost always true, and flushing out local mark stacks is inexpensive. I also think it's a somewhat nice/simplifying invariant, that all stacks are published on the stripes when worker threads start working.

[pliden]

We might also want to poke out mark stacks on the VM thread when we handshake threads, using a concurrent VM operation. But maybe that is a problem for another day.

Yes, I do that in a separate patch I have in the works (which aims to simplify mark termination/flushing, and make it more robust).

[pliden]

/integrate

[openjdk]

@pliden Since your change was applied there have been 8 commits pushed to the master branch:

• 19219a9: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0()
• 5d4a135: 8253842: [JVMCI] Allow implicit exception to dispatch to other address in jvmci compilers.
• 289ae79: 8252998: ModuleWrapper.gmk doesn't consult include path
• 9604ee8: 8248238: Implementation: JEP 388: Windows AArch64 Support
• 1c2754b: 8253269: The CheckCommonColors test should provide more info on failure
• d296708: 8253606: Need to add missed constructor to the SwingEventMonitor
• 5810238: 8253945: Missed default constructor for StreamPrintServiceFactory.java
• 123e786: 8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test

Your commit was automatically rebased without conflicts.

Pushed as commit 65cab55.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.