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.

Great analysis, makes sense. 

The test paths I see in the test system is about 80 characters.

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

Marked as reviewed by egahlin (Reviewer).

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