RFR: 8298377: JfrVframeStream causes deadlocks in ZGC [v2]

Markus Grönlund mgronlun at openjdk.org
Tue Jan 3 13:59:53 UTC 2023


On Fri, 23 Dec 2022 14:53:38 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> The JfrVFrameStream is used while generating stack traces for events. One of the events are the ZPage allocation event. This event is sometimes sent when ZGC is relocating. The current implementation of JfrVFrameStream uses WalkContinuation::include, which causes JFR to walk the continuation and perform GC barriers. This is problematic, since ZGC has a requirement that we never perform load barriers while running the relocation code. If we do, we might end up performing other reloctions from the the relocation code, and in some cases that causes dead locks. 
>> 
>> I propose that JFR doesn't walk the stack during stack watermark processing. This PR implements that change. This PR replaces https://github.com/openjdk/jdk/pull/11586
>
> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix release build

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 391:

> 389: 
> 390:   bool ret = false;
> 391:   StackWatermarkSet::start_processing(thread, StackWatermarkKind::gc);

Is this now needed unconditionally, for all threads sampled? What is the overhead of introducing it?

src/hotspot/share/runtime/deoptimization.cpp line 759:

> 757:     // clear it to make sure JFR understands not to try and walk stacks from events
> 758:     // in here.
> 759:     DisableStackTracingMark dstm(thread);

You replace the old system in Deopt, with the new formalized method? Ok.

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

PR: https://git.openjdk.org/jdk/pull/11778


More information about the hotspot-dev mailing list