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
------------------------------------------------------------------------------
src/hotspot/share/runtime/init.cpp
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