On Mon, 22 Sep 2025 21:14:06 GMT, Chris Plummer <[email protected]> wrote:
>> 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?
> 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?
This is a right question to ask, thanks. I agree this confusing. The issue is
with the pure continuations which are executed not in a context of a virtual
thread. Without this check the following test is stably failed:
test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest
I'm currently kind of puzzled on how to make this check better.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373659467
