NotifyFramePop and FramePop events

[JC Beyler]

Hi all,

I was asked to raise a question about NotifyFramePop and FramePop events
and I thought I would just ask it here:

If we imagine we have a stack frame such as:

call_depth0
  call_depth1
    call_depth2
       call_depth3

And at this third depth, we request a frame pop when leaving depth1 via the
NotifyFramePop call. We would of course assume that when leaving
call_depth1 we get a FramePop event.

Now imagine that we disable the frame pop event notification in call_depth2:
call_depth0
  call_depth1
    call_depth2
       SetEventNotificationMode
<https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#SetEventNotificationMode>(JVMTI_DISABLE,
JVMTI_EVENT_FRAME_POP, NULL)

If the stack now pops back to call_depth0, the frame pop system is not
checked, the FramePop for call_depth1 is not issued either.

However, imagine now that later down the road, the stack trace has built
itself back up and we enabled the event:
call_depth0
  second_call_depth1
    second_call_depth2
       SetEventNotificationMode
<https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#SetEventNotificationMode>(JVMTI_ENABLE,
JVMTI_EVENT_FRAME_POP, NULL)

Then when leaving second_call_depth1, we seemingly will issue a frame pop
event.

Here is the qualm:
  - It seems counter intuitive and the documentation does not specify/warn
about this; it seems that if you disable the events you should perhaps
clear up the pop requests.
  - At least the documentation for NotifyFramePop (
https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#NotifyFramePop)
should be changed since it says: "When the frame that is currently at depth
is popped from the stack" to something like "When the first frame at the
depth is popped from the stack and the event notification is enabled"

Therefore the questions are:

1) Is this such a corner case, that we do not wish to try to fix the
documentation or the code?
2) Is this a corner case we do not wish to handle, therefore put a fix in
the documentation to at least warn users of this
3) Is this a bug that we'd like to fix?

Thanks for your insight,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170831/f0853238/attachment.html>