8368159: Significant performance overhead when started with jdwp agent and unattached debugger #27403

sspitsyn · 2025-09-20T04:40:16Z

This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown.
The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the jvmti_yield_cleanup() recursively calling JvmtiExport::continuation_yield_cleanup(). The reason of this overhead is because the function JvmtiExport::can_post_frame_pop() is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: bool JvmtiExport::has_frame_pops(JavaThread* thread).

Testing:

Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent
Mach5 tiers 1-6 are all passed

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8368159: Significant performance overhead when started with jdwp agent and unattached debugger (Bug - P4)

Reviewers

Leonid Mesnik (@lmesnik - Reviewer)
Chris Plummer (@plummercj - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403
$ git checkout pull/27403

Update a local copy of the PR:
$ git checkout pull/27403
$ git pull https://git.openjdk.org/jdk.git pull/27403/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27403

View PR using the GUI difftool:
$ git pr show -t 27403

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27403.diff

Using Webrev

Link to Webrev Comment

…t and unattached debugger

bridgekeeper · 2025-09-20T04:42:17Z

👋 Welcome back sspitsyn! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-09-20T04:43:31Z

@sspitsyn This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8368159: Significant performance overhead when started with jdwp agent and unattached debugger

Reviewed-by: lmesnik, cjplummer

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 193 new commits pushed to the master branch:

2aafda1: 8366948: AOT cache creation crashes when iterating training data
a2870d6: 8368015: Shenandoah: fix error in computation of average allocation rate
17accf4: 8368174: Proactive initialization of @AOTSafeClassInitializer classes
... and 190 more: https://git.openjdk.org/jdk/compare/3eb3e0dcb0aa06fe427adeeaa40b9568c7f07ee8...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-09-20T04:44:06Z

@sspitsyn The following labels will be automatically applied to this pull request:

hotspot
serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-09-20T04:47:47Z

Webrevs

lmesnik · 2025-09-20T17:32:35Z

src/hotspot/share/runtime/continuationFreezeThaw.cpp


 static void invalidate_jvmti_stack(JavaThread* thread) {
-  if (thread->is_interp_only_mode()) {
+  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. I may need to look at this test more time to make sure it is fully correct.

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.

I was thinking a lot on how to get rid of this current stack depth recalculation mechanism used in interp_only mode but have not come with a good approach yet. We have a constant trouble from this mechanism needed for debugger optimization purposes.

The interp_only check is needed for optimization to avoid a performance overhead of current stack depth invalidation.

But if we are not in interp_only mode isn't it already invalidated?

But if we are not in interp_only mode isn't it already invalidated?

It does not need to be invalidated if not in interp_only mode as it should not be used there or has to be explicitly invalidated exactly where it is needed (the frame pops cleaning code for plain Continuations). The issue I see is only with the test test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest which is for plain Continuations. Otherwise, the invalidate_jvmti_stack() would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuations lurking somewhere.

My point is we could just unconditionally invalidate. It would do no harm. It would not be invalidating a curr stack depth that could later be used.

Okay, thanks! I'll make it unconditional. I do not see any performance degradation with that. Also, it will keep the test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest test passed.

sspitsyn · 2025-09-25T05:39:17Z

Chris and Leonid, thank you for review!

sspitsyn · 2025-09-25T05:39:33Z

/integrate

openjdk · 2025-09-25T05:41:35Z

Going to push as commit 17244c6.
Since your change was applied there have been 193 commits pushed to the master branch:

2aafda1: 8366948: AOT cache creation crashes when iterating training data
a2870d6: 8368015: Shenandoah: fix error in computation of average allocation rate
17accf4: 8368174: Proactive initialization of @AOTSafeClassInitializer classes
... and 190 more: https://git.openjdk.org/jdk/compare/3eb3e0dcb0aa06fe427adeeaa40b9568c7f07ee8...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-09-25T05:41:43Z

@sspitsyn Pushed as commit 17244c6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8368159: Significant performance overhead when started with jdwp agen…

0f63bb1

…t and unattached debugger

openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Sep 20, 2025

openjdk bot added the rfr Pull request is ready for review label Sep 20, 2025

fix minimal build broken by incorrect macro usage

4b0478f

lmesnik reviewed Sep 20, 2025

View reviewed changes

review: remove unneeded condition from invalidate_jvmti_stack()

52309bc

lmesnik approved these changes Sep 25, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 25, 2025

plummercj approved these changes Sep 25, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Sep 25, 2025

openjdk bot closed this Sep 25, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 25, 2025

8368159: Significant performance overhead when started with jdwp agent and unattached debugger #27403

8368159: Significant performance overhead when started with jdwp agent and unattached debugger #27403

Uh oh!

Conversation

sspitsyn commented Sep 20, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Sep 20, 2025

Uh oh!

openjdk bot commented Sep 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Sep 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Sep 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

lmesnik Sep 20, 2025

Choose a reason for hiding this comment

Uh oh!

plummercj Sep 22, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sspitsyn Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

plummercj Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sspitsyn Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plummercj Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn Sep 25, 2025

Choose a reason for hiding this comment

Uh oh!

sspitsyn commented Sep 25, 2025

Uh oh!

sspitsyn commented Sep 25, 2025

Uh oh!

openjdk bot commented Sep 25, 2025

Uh oh!

openjdk bot commented Sep 25, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

sspitsyn commented Sep 20, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Sep 20, 2025 •

edited

Loading

openjdk bot commented Sep 20, 2025 •

edited

Loading

mlbridge bot commented Sep 20, 2025 •

edited

Loading

sspitsyn Sep 23, 2025 •

edited

Loading

plummercj Sep 24, 2025 •

edited

Loading

sspitsyn Sep 24, 2025 •

edited

Loading