The stack depth counting was put in place as an optimization in
fullspeed debugging changes. However, it's currently not
maintained properly, which relies on method_entry_on and method_exit_on
to be turned on. In addition, it's used together with interp_only_mode flag,
which is not consistently turned on in -Xint and -Xmixed/-Xcomp mode.
Bug 4546478 (Enabling a watchpoint can kill following NotifyFramePops)
is caused by this problem.
The whole recompute_method_entry_and_exit_on mechanism and its use
must be cleaned up.
Here are a few suggestions from Robert:
All these cross linked states and state transitions are too
baroque for words - and I think near to impossible to get
correct. All this stack depth counting was put in place as
an optimization. I think it may have been a premature
optimization and it certainly muddies the code. I think there
are two simplifying options --
1) Don't use the optimization for nFrames, but still use it
when MethodEntry/Exit is on or a FramePop is active. Then
recompute_method_entry_and_exit_on() should be given exclusive
domain to turn on and off internal MethodEntry/Exit. And it
would initialize stack depth counting at an on transition.
It would no longer include an is_interp_only_mode() test.
2) Chuck the optimization and count the frames every time.
recompute_method_entry_and_exit_on() still must be cleaned up
and probably should still be the access point for internal
MethodEntry/Exit.
-Robert
Another thing to clean up is that method_entry_on/method_exit_on
and interp_only_mode should be turned on when there are active
NotifyFramePop requests but not any time FRAME_POP event is enabled.
fullspeed debugging changes. However, it's currently not
maintained properly, which relies on method_entry_on and method_exit_on
to be turned on. In addition, it's used together with interp_only_mode flag,
which is not consistently turned on in -Xint and -Xmixed/-Xcomp mode.
Bug 4546478 (Enabling a watchpoint can kill following NotifyFramePops)
is caused by this problem.
The whole recompute_method_entry_and_exit_on mechanism and its use
must be cleaned up.
Here are a few suggestions from Robert:
All these cross linked states and state transitions are too
baroque for words - and I think near to impossible to get
correct. All this stack depth counting was put in place as
an optimization. I think it may have been a premature
optimization and it certainly muddies the code. I think there
are two simplifying options --
1) Don't use the optimization for nFrames, but still use it
when MethodEntry/Exit is on or a FramePop is active. Then
recompute_method_entry_and_exit_on() should be given exclusive
domain to turn on and off internal MethodEntry/Exit. And it
would initialize stack depth counting at an on transition.
It would no longer include an is_interp_only_mode() test.
2) Chuck the optimization and count the frames every time.
recompute_method_entry_and_exit_on() still must be cleaned up
and probably should still be the access point for internal
MethodEntry/Exit.
-Robert
Another thing to clean up is that method_entry_on/method_exit_on
and interp_only_mode should be turned on when there are active
NotifyFramePop requests but not any time FRAME_POP event is enabled.
- relates to
-
JDK-4546478 Enabling a watchpoint can kill following NotifyFramePops
-
- Resolved
-