RFR: 8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent

[Roman Kennke]

Hi Alan,

> On 15/07/2020 18:20, rkennke at 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