On Thu, 2 Mar 2023 03:54:39 GMT, Sergey Bylokhov <s...@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
