On Tue, 23 Sep 2025 23:18:19 GMT, Serguei Spitsyn <[email protected]> wrote:
>> 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. > 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? I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373663413
