On Fri, 5 Jun 2026 17:21:12 GMT, Chris Plummer <[email protected]> wrote:
>> Overall, it looks good. It is my long time dream to get rid of this >> mechanism. :) >> Thank you for this attempt to do this! >> 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. > >> 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31389#issuecomment-4723389886
