RFR: 8249543: Force DirectBufferAllocTest to run with -ExplicitGCInvokesConcurrent
Roman Kennke
rkennke at redhat.com
Thu Jul 16 09:19:21 UTC 2020
On Thu, 2020-07-16 at 08:09 +0100, Alan Bateman wrote:
> On 15/07/2020 20:47, Roman Kennke wrote:
> > :
> > 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?)
> >
> Just surprised that more tests aren't impacted. RMI DGC wouldn't
> work
> with a STW collector if explicit GC were disabled.
Yeah, but +ExplicitGCInvokesConcurrent doesn't disable System.gc(), it
only turns it into a concurrent cycle with the calling thread waiting
for it to comlete. That is semantically very close to what STW
System.gc() does.
DirectBufferAllocTest is only problematic because it is not reliable as
it is, and the added concurrency makes it worse, as far as I can tell.
> I haven't heard of
> deployment using it with a concurrent GC but maybe it's okay. I'm
> just
> surprised that the RMI tests in the jdk repo are robust enough to
> pass,
> I would have guessed they might need attention (the test group is
> jdk_rmi but it sounds like you might be running those already).
I've just run it again with my setup and it all passes.
You ok with the patch?
Thanks,
Roman
More information about the core-libs-dev
mailing list