On Tue, 16 Jun 2026 20:37:13 GMT, Daniel D. Daugherty <[email protected]> wrote:
>>> However, I still have a performance concern which I'd prefer to discuss >>> offline. This potential performance issue held me of this simplification >>> before. My concern is about `PopFrame` related fragment in the function >>> `post_method_exit_inner()`. If stack is big and the `interp_only_mode` has >>> been already enforced for target thread which has and a `FramePop` request >>> then recalculation of current stack depth can give a significant >>> performance overhead. At least, we need to somehow mitigate this issue and >>> measure the performance impact with a specific benchmark test. >> >> We also need to consider how much this feature actually helped. Do we have a >> good understanding of when the stack depth actually remains cached, thus >> avoiding the recalculation? Is this happening in performance critical code? >> You mentioned `FramePop` support. Does the cost of computing the stack depth >> matter when we are debugging? > > @plummercj - This PR needs two reviewers. I've just done another crawl thru > review and > I'm happy with the fix. I believe @dholmes-ora is out of the office so if you > could chime in > on this PR again. > > @lmesnik - How is your current testing going? > > Also you should update the PR's description note to include a summary of > the revised approach. @dcubed-ojdk, @plummercj, @sspitsyn, @dholmes-ora Thank you for review! The standard (tier5) testing for svc completed. The stress test reproducing the failure passed several times. It failed quite often before the fix. Unfortunately, complete removal of cache might hit performance for real world debugging, so I am pushing this fix. It should be enough to cover cases where cache is not valid and doesn't affect other cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31389#issuecomment-4724805902
