RFR: 8257621: JFR StringPool misses cached items across consecutive recordings

[Erik Gahlin]

On Wed, 2 Dec 2020 20:20:55 GMT, Jie Kang <jkang at openjdk.org> wrote:

> This addresses 8257621 by resetting the Java cache when a recording is stopped and there are no other recordings still running. The reproducer described in 8257621 no longer exhibits the bug with this change. However, I'm not sure if there are other edge cases missed, or if this fits with the expected design of the StringPool, Recording and Chunk systems. Any insight would be appreciated; I'm willing to adjust as needed.
> 
> On:
> Linux (Fedora 31), jtreg 5.1-b01 configured with flags --disable-warnings-as-errors --with-jtreg=/path/to/jtreg-5.1-b01/
> 
> I have run the following with this patch applied:
> `make run-test TEST=":jdk_jfr"`
> `make run-test-tier1`
> 
> The test `jdk.jfr.api.event.TestShouldCommit` fails for me but I believe it is fragile and not relevant to the change proposed here.

This looks like the same issue as in https://bugs.openjdk.java.net/browse/JDK-8256482, which started to happen after the pool started to count at 1 instead of 0.

Do you know why the change of the pool id provoked the error? And if, or why, this fixes the problem?

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

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