Hi Alan, > On 15/07/2020 18:20, rken...@redhat.com wrote: > > DirectBufferAllocTest is unreliable when running with > > +ExplicitGCInvokesConcurrent, because allocating DBB spreads > > System.gc() calls all over concurrent GC cycles. It becomes more > > reliable when running with -ExplicitGCInvokesConcurrent. > > (Shenandoah > > defaults to +ExplicitGCInvokesConcurrent, other GCs don't as far as > > I > > know.) > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8249543 > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8249543/webrev.00/ > > > > Ok? > > > I guess this is okay but if -ExplicitGCInvokesConcurrent is the > default > then doesn't it break RMI DGC?
Why would it? Can you explain? (-ExplicitGCInvokesConcurrent is the default for all GCs but Shenandoah, and has been that way forever. Do you mean +ExplicitGCInvokesConcurrent?) Here's some context from our perspective: Normally, when System.gc() is called, it invokes a STW garbage collection. For most GCs that has been that way forever. This is what -ExplicitGCInvokesConcurrent implies. In Shenandoah, we opted to do +ExplicitGCInvokesConcurrent instead. This means that when System.gc() is called, a *concurrent* collection cycle is started, and the calling thread will wait for that to complete (and other threads will keep on running - unless they also call System.gc() ). It breaks this test because all test threads are hammering the GC with System.gc(), the first one will trigger the start of a concurrent GC, and the other ones will line up while concurrent GC is running. This is normally ok. However, the test (or even DirectByteBuffer allocation routine in Bits.java) is also over-assuming that when System.gc() returns (and Cleaner thread did its thing), it could now allocate native memory. However, when lots of test threads are competing for this, the last one could already been outrun by the first ones that are rescheduled already. The additional concurrency introduced by concurrent GC, plus a bunch of wrinkles in our implementation (e.g. the cleaner can run concurrently with ongoing GC, and not after the GC as it would do with STW GC) makes this test spuriously fail with Shenandoah. Forcing it to -ExplicitGCInvokesConcurrent makes it more reliable. But as far as I can tell, the test is intrinsically unreliable, but I'm also not sure how it could be made better (or the DBB allocator even). > Are you sure this is the only test that > fails? So far, yes. Can you point me to specific tests that you would expect to fail? Roman
