| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8290111 | 20 | Markus Grönlund | P3 | Resolved | Fixed | b06 |
| JDK-8291410 | 19.0.2 | Markus Grönlund | P3 | Resolved | Fixed | b01 |
| JDK-8291253 | 19.0.1 | Markus Grönlund | P3 | Resolved | Fixed | b04 |
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.
- backported by
-
JDK-8290111 JFR: Thread checkpoint no longer enforce mutual exclusion post Loom integration
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- duplicates
-
JDK-8288592 JVMTI GetClassSignature/getclsig005 failed "assert(_adapter.pos() == this->start_pos()) failed: invariant"
-
- Closed
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
