RFR: 8279662: serviceability/sa/ClhsdbScanOops.java can fail do to unexpected GC

[Kevin Walls]

On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test is failing to find certain types in the scanoops output when run with -Xcomp. This is happening in the loom repo. The reason it is happening there is because loom introduced a full GC during codecache sweeping. The test only runs scanoops on the eden gen, and the full GC is causing objects of certain expected types to no longer be present in the eden gen. The fix is to also check the old gen.
> 
> The logic of the test had to be reworked a bit to accomplish checking the output of two scanoops commands together. It was relying on the ClhsdbLauncher class to check the output for expected strings, but in this case we need to accumulate the output of the two scanoops commands and check the combined output for the expected strings, so now the checking is done directly by the test and not by ClhsdbLauncher.
> 
> I'm choosing to fix this in the jdk repo rather than the loom repo since it is a latent bug that theoretically could occur even without the loom changes, and also to help reduce the amount of changes to be reviewed when loom is integrated into jdk.

Looks good.  
For the scanoops for a type, it seems like a reasonable assumption that there will be a String in the old gen!

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7295