Greetings, Before integrating Loom and Virtual Threads, threads writing checkpoint meta-information claimed a checkpoint buffer from a list categorized as thread-local. Buffers on this list are not reset eagerly as part of a flushpoint but only as part of chunk rotation, where the JFR Recorder Thread has exclusive access by issuing a prior epoch shift. With Loom, the thread-local buffers are exclusively dedicated to meta-information for Virtual Threads. The meta-information about the JVM thread, for example, the carrier thread, is written to a buffer located on the list categorized as global. Buffers on this list are reset eagerly during flushpoints. Before Loom, an invariant for this global list was that only the JFR Recorder Thread used it. This invariant no longer holds. The JFR Recorder Thread will reset buffers on this list without protection and can do so in the middle of another thread's attempted writes. Some consequences are asserts in debug builds and data loss in product builds. Some mutex mechanism for the buffers on the global list must be re-introduced to prevent the JFR Recorder Thread from resetting buffers currently in use. This change set adds back proper protection. Testing: jdk_jfr, stress Thanks Markus ------------- Commit messages: - 8288592 Changes: https://git.openjdk.org/jdk19/pull/108/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=108&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288592 Stats: 51 lines in 3 files changed: 16 ins; 2 del; 33 mod Patch: https://git.openjdk.org/jdk19/pull/108.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/108/head:pull/108 PR: https://git.openjdk.org/jdk19/pull/108