RFR: 8221392: Reduce ConcurrentGCThreads spinning during start up

Kim Barrett kim.barrett at oracle.com
Mon Mar 25 15:08:10 UTC 2019

> On Mar 25, 2019, at 4:36 AM, Per Liden <per.liden at oracle.com> wrote:
> During startup, ConcurrentGCThreads end up in a loop sleeping for 1ms over and over (typically 30-50 times), until is_init_completed() is true. This is not optimal, and we should instead have them wait until they are signaled. This problem has been observed before, as comments in JDK-8136854 suggests.
> This patch introduces wait_init_completed(), which will block until set_init_completed() is called. Note that the newly introduced InitCompleted_lock is only used to control the interaction between wait_init_completed() and set_init_completed(). is_init_completed() is still lock-free and was just cleaned up to use proper atomic load_acquire/release_store semantics.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221392
> Webrev: http://cr.openjdk.java.net/~pliden/8221392/webrev.0
> /Per

 203   OrderAccess::release_store(&_init_completed, true);

I don't think this needs a release_store.  If it did, then the access
in the wait_init_completed loop should also be barriered.  But since
both of those are under the lock...


Looks good, other than that.  I don't need a new webrev for removal of
the unnecessary release_store.

More information about the hotspot-gc-dev mailing list