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

[Jie Kang]

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.

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

Commit messages:
 - Fix stringpool cache behavior

Changes: https://git.openjdk.java.net/jdk/pull/1576/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1576&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257621
  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1576.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1576/head:pull/1576

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