RFR: 8300727: java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java failed with "List wasn't garbage collected"

Alexey Ivanov aivanov at openjdk.org
Thu Mar 2 12:23:16 UTC 2023


On Thu, 2 Mar 2023 03:54:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > If the default collector started ignoring System.gc() it would trigger lots of test failures which would make
> 
> It is up to you, but I disagree. There was an agreement in the team to use one approach to trigger the gc, that approach was used in most of our tests, and was used in this test as well.

Do you agree that using only `System.gc` is more concise than generating OOME?

If `System.gc` is enough for testing `Reference` classes, why does the client libs team need to generate OOME? Our tests use the `Reference` classes to check if an object is garbage-collected.

So far, your argument is that this test is *now* different from other tests which employ both `System.gc` and OOME.

> > I would absolutely explore this route and would be happy to update other tests but this is out of scope for this issue.
> 
> I agree that it is out of the scope of this issue, which actually fixed by adding the "retry" step to the test. The bug is unrelated to the replacing of OOM by the System.gc(). When why did you change it?

I already answered this question several times. I followed the piece of advice in the [JBS comment](https://bugs.openjdk.org/browse/JDK-8300727?focusedCommentId=14560139&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14560139): _“This is not the way to provoke a full GC in a test reliably. Just use System.gc(). See e.g. [`test/jdk/java/lang/ref/PhantomReferentClearing.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/ref/PhantomReferentClearing.java).”_

That's what I did. Using `System.gc()` proved to be successful and, in my opinion, it looks cleaner than generating OOME.

I had a handful of attempts which still failed.

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

PR: https://git.openjdk.org/jdk/pull/12594



More information about the client-libs-dev mailing list