RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
Markus Grönlund
mgronlun at openjdk.org
Fri May 16 18:58:00 UTC 2025
On Fri, 16 May 2025 18:54:03 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
>> I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.
>
>> I'm happy with things except ensuring this horrible JVMTI force early return + method exit notification + GC stuff works. I'm off next week, so I'll leave it to someone that enjoys staring at JVMTI code more than I do to validate its correctness, unless this is still under review when I get back.
>
> Thanks so much for your help Erik. I am juggling some alternatives so see what we can do here.
> @mgronlun: I don't think I can get the top frame hiding trick to work on PPC64. What we need to do is to hide the top interpreter frame from the sampler after the return safepoint check, right? If I hide it from the sampler, I will also hide it from the concurrent thread stack processing code. And that causes errors. I think the top frame hiding trick only works on platforms which use an FP register. Platforms like PPC64 and s390 don't have that. Can we use a different mechanism to prevent the sampler from taking snapshots between the return safepoint check and the frame pop? E.g., we could set a field in the JavaThread before the safepoint check and clear it after the frame pop. The sampler would have to discard samples when the JavaThread's field is set.
Thanks Martin,
I am elaborating some alternative implementation ideas to help (dis)solve this.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2887461607
More information about the hotspot-jfr-dev
mailing list