[jdk17] RFR: 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out

[Per Liden]

On Thu, 24 Jun 2021 20:57:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of
> vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java to
> eliminate races that can lead to the test occasionally timing out.
> 
> When the referent being tested by a particular iteration is a finalizable
> class, the test invoked eatMemory() repeatedly until the referent's
> finalize() function set a flag.  Then, whether the referent is finalizable
> or not, there is a call to eatMemory() to cause the phantom reference to be
> cleared and notified.  The testing thread then proceeds to wait for the
> reference to be notified.
> 
> This has a problem with ZGC.  One collection made the referent finalizable.
> Reference processing and finalization will end up ensuring it will survive
> the following collection.  If the post-finalization eatMemory() is that next
> collection, then it won't clear and notify the associated PhantomReference.
> Usually that doesn't cause a problem because the referent will be reclaimed
> by some other thread's later call to eatMemory().  But if the test is done
> and terminating, there won't be a later GC, and the wait for notification
> will block until the test times out.
> 
> There are other, rarer, scenarios with various collectors that could lead to
> similar timeouts, but the one described above is "relatively" likely.
> 
> While investigating this issue I did a bunch of code cleanup (for example,
> there was some really badly formatted code), refactoring, and commenting.
> As a result, a large fraction of the test has changed, though mostly in ways
> that don't affect it's function.  The first of the two commits in the PR is
> a whitespace-only cleanup.  Excluding it may make reviewing easier.
> 
> Testing:
> Ran the phantom002 test a couple thousand times.
> 
> Using a modified version of the test, verified that the described problem
> case actually occurs, on the order of 1% of the time.

Looks good.

-------------

Marked as reviewed by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/142