-
Bug
-
Resolution: Fixed
-
P4
-
21, 25, 26
-
b18
This issue is pretty much observable with millions of virtual threads and 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 that precise and triggers unneeded work when debugger has not been attached yet.
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 that precise and triggers unneeded work when debugger has not been attached yet.
- causes
-
JDK-8369482 JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state
-
- New
-
- relates to
-
JDK-8369609 Continuations preempt_epilog is missing a call to invalidate_jvmti_stack
-
- New
-
- links to
-
Commit(master) openjdk/jdk/17244c69
-
Review(master) openjdk/jdk/27403