RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2]
Chris Plummer
cjplummer at openjdk.org
Mon Sep 22 21:16:45 UTC 2025
On Sat, 20 Sep 2025 17:32:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>>
>> fix minimal build broken by incorrect macro usage
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622:
>
>> 1620:
>> 1621: static void invalidate_jvmti_stack(JavaThread* thread) {
>> 1622: if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) {
>
> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only?
> It is invalidated once thread switched to interp only.
It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2370319721
More information about the serviceability-dev
mailing list