RFR: 8241456: ThreadRunner shouldn't use Wicket for threads starting synchronization

Leonid Mesnik leonid.mesnik at oracle.com
Thu Mar 26 21:39:15 UTC 2020


Replying with correct summary.

Leonid

On 3/23/20 8:55 PM, Leonid Mesnik wrote:
> Hi
>
> Could you please review following fix which update ThreadsRunner to use AtomicInteger/spinOnWait instead of Wicket to synchronize starting of stress test threads.
>
> Failing tests allocated all memory by earlier started threads before Lock.unlock is called in the latest threads. So thread might get an OOME exception while trying to release lock and/or get into inconsistent state.
>
> The bug was introduced by https://bugs.openjdk.java.net/browse/JDK-8241123 <https://bugs.openjdk.java.net/browse/JDK-8241123>
> The Atomic works fine for stress test finishing sync. I just didn't expect that tests might OOME while releasing start lock.
> Verified that tests now don't fail with -Xcomp -server -XX:-TieredCompilation -XX:-UseCompressedOops.
>
> webrev: http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/ <http://cr.openjdk.java.net/~lmesnik/8241456/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8241456 <https://bugs.openjdk.java.net/browse/JDK-8241456>
>
> Leonid



More information about the hotspot-gc-dev mailing list