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

[Tony Printezis]

Hi Kim,

I’ll be happy to try trouble-shooting this. It's clearly of interest to us
as we do use CMS and it’d be nice to get the tests to finish quicker. I
tried reproducing the 20sec durations for the child processes with CMS but
I was not able to. They seem to have more or less the same duration as with
the other GCs. Do you remember which tests you saw this issue in? Also,
what type of machine did you run on (“small” laptop, “larger” workstation,
etc)?

BTW, meant to say along with my review: I tried your patch locally and it
shaved off around 35% of the elapsed time for the gc/arguments tests on my
workstation. So a nice improvement! Thanks!

Tony


—————
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On July 8, 2019 at 5:08:21 PM, Kim Barrett (kim.barrett at oracle.com) wrote:

> 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.