[jdk19] RFR: 8289692: JFR: Thread checkpoint no longer enforce mutual exclusion post Loom integration [v2]

Robbin Ehn rehn at openjdk.org
Thu Jul 7 12:20:45 UTC 2022


On Wed, 6 Jul 2022 10:12:25 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> 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
>
> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Thank, looks good.

src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.inline.hpp line 96:

> 94: static void retired_sensitive_acquire(Type* t, Thread* thread) {
> 95:   assert(t != NULL, "invariant");
> 96:   assert(thread != nullptr, "invariant");

Maybe add assertion that thread is current.

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/109


More information about the hotspot-jfr-dev mailing list