RFR: 8217170: gc/arguments/TestUseCompressedOopsErgo.java timed out

[Kim Barrett]

> On Jul 7, 2019, at 8:35 AM, Tony Printezis <tprintezis at twitter.com> wrote:
> 
> Kim,
> 
> If the tests start with a very small initial heap, CMS will set the young gen size to something very small and then not resize it during the run. This results in an unnecessarily high young GC overhead. We’ve seen that in quite a few occasions. Could this be the reason for the child processes taking a long time with CMS?

Maybe?  These tests mostly don’t specify minimum or initial heap sizes, except where
doing so is part of what is being tested.  But I don’t know if we’re even doing any GCs
in the child processes; most of them are just ‘java <options> -version’.  Having some
default option values or behaviors that sometimes makes that really slow seems like
a problem, right?  But maybe part of the answer might be that CMS is the wrong GC to
use in production for small, short-lived applications?

I’m not sure how much effort I’ll be able to put into running to ground the CMS-specific
part of this problem.  CMS has been deprecated for a while, and isn’t getting a lot of
resources allocated to non-critical problems.