JFR StringPool misses cached items across consecutive recordings

When an event String is cached via the StringPool, it's entry in the Java layer cache persists across consecutive recordings. This causes events in the next recording to have a missing String entry as the native layer is never asked to emit a constant pool entry for it.

Following is a minimal reproducer for the issue. When examining the produced .jfr files, you'll find the first contains events with the string associated correctly from the constant pool, while the second contains events with N/A for the string value and the constant pool has no entries for Strings.

TestConsecutiveRecording.java

import jdk.jfr.Description;
import jdk.jfr.Event;
import jdk.jfr.Label;
import jdk.jfr.Recording;

import java.io.File;
import java.io.IOException;
import java.nio.file.Path;

public class TestConsecutiveRecording {
    @Label("String Event")
    @Description("An event with a string payload")
    public static class StringEvent extends Event {
        @Label("Message")
        public String message;
    }

    public static void main(String[] args) throws IOException {
        String name = "One";
        Recording r = new Recording();
        Path destination = File.createTempFile(name, ".jfr").toPath();
        r.setDestination(destination);

        r.start();
        for (int i = 0; i < 2; i++) {
            StringEvent event = new StringEvent();
            event.message = "Event has been generated!";
            event.commit();
        }
        r.stop();
        r.close();

        name = "Two";
        r = new Recording();
        r.start();
        for (int i = 0; i < 2; i++) {
            StringEvent event = new StringEvent();
            event.message = "Event has been generated!";
            event.commit();
        }
        r.stop();
        destination = File.createTempFile(name, ".jfr").toPath();
        r.dump(destination);
        r.close();
    }
}