On Thu, 23 Feb 2023 23:12:02 GMT, Phil Race <p...@openjdk.org> wrote:
>> 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). >> >> If using `System.gc()` is good enough for testing references: >> >> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60 >> >> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92 >> >> Then it should be good enough for this test too. >> >> Perhaps, the same effect could be achieved by causing OOME in a loop. >> However, using `System.gc()` makes the intention clearer: *run GC*, wait for >> the phantom reference to be cleared and enqueued. >> >> I can explicitly select a GC: `-XX:+UseG1GC` (default) or `-XX:+UseSerialGC`. > > There are lots of tests that rely on System.gc() actually triggering a gc. > SFAIK all collectors we have today will obey it unless you use > -XX:+DisableExplicitGC > If you can make the test work with that then that would be interesting but > calling just System.gc() is no worse than all those other tests. Many client tests generate OOM for that, we have a special Util, see the usage of Util.generateOOME() or various implementation of generateOOME. If the OOM + sleep(to give the GC a chance to clean the weakrefs in case of slow systems) does not work, then could it be considerred as a GC bug? >OutOfMemoryError: The Java Virtual Machine implementation has run out of >either virtual or physical memory, and the automatic storage manager was >unable to reclaim enough memory to satisfy an object creation request. https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-6.html#jvms-6.3 ------------- PR: https://git.openjdk.org/jdk/pull/12594
