Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2036439 | 1.4.0 | Daniel Daugherty | P2 | Resolved | Fixed | beta |
Arnaud Weber of PacBell for Claire Normand at Intuitive reports:
10-02-00 Karen Kinnear
Arnaud Weber sent us an update which said that the original
bug report (still included below) was inaccurate and the following
is the bug they are actually seeing:
The problem is that if a jvmpi agent enables method_entry2 and
method_exit, method_exit events are never generated. This problem
goes away if we use method_entry events instead of method_entry2.
Original bug report:
When calling GetCallTrace() JVMPI agents provide a buffer to be filled and
a depth which is the max number of frame F. The returned buffer contains:
[F0, F1, F2, ... Fn-2, Fn-1]
where n is the current number of frames for the thread which JNIEnv is given to
GetCallTrace().
If the buffer is too small to fit the number of frames, JVMPI truncates the
call trace.
Unfortunately, the classic vm jvmpi implementation truncates the beginning of the
call trace and the hotspot jvmpi implementation truncates the end. For example
if you call GetCallTrace for a thread which has n frames (n > 2) and you give a max depth = 2, you'll get:
[Fn-2, Fn-1] with classic
[F0, F1] with hotspot
This is unfortunate because providing a very small depth is a common
technique that profilers use while processing METHOD_ENTRY events.
When processing METHOD_ENTRY events, deterministic profilers have a stack
and don't need the whole call trace. They typically need the new frame
for the method that was just entered. (METHOD_ENTRY events don't have
methodIDs and are very fast).
Asking JVMPI for the last frame is a lot faster than asking for the whole
stack trace, hoever this can not be done if jvmpi truncates the last
frames.
If for some reason, you cannot fix this we can always switch to METHOD_ENTRY2
events, however, we are not sure that other vms support METHOD_ENTRY2 events
properly and we'll have to implement a special case for hotspot. (use
METHOD_ENTRY2 if hotspot is detected). We are trying to minimize special
cases and it would really help us if hotspot's jvmpi implementation
could work exactly like the classic jvmpi implementation when this
edge case occurs.
10-02-00 Karen Kinnear
Arnaud Weber sent us an update which said that the original
bug report (still included below) was inaccurate and the following
is the bug they are actually seeing:
The problem is that if a jvmpi agent enables method_entry2 and
method_exit, method_exit events are never generated. This problem
goes away if we use method_entry events instead of method_entry2.
Original bug report:
When calling GetCallTrace() JVMPI agents provide a buffer to be filled and
a depth which is the max number of frame F. The returned buffer contains:
[F0, F1, F2, ... Fn-2, Fn-1]
where n is the current number of frames for the thread which JNIEnv is given to
GetCallTrace().
If the buffer is too small to fit the number of frames, JVMPI truncates the
call trace.
Unfortunately, the classic vm jvmpi implementation truncates the beginning of the
call trace and the hotspot jvmpi implementation truncates the end. For example
if you call GetCallTrace for a thread which has n frames (n > 2) and you give a max depth = 2, you'll get:
[Fn-2, Fn-1] with classic
[F0, F1] with hotspot
This is unfortunate because providing a very small depth is a common
technique that profilers use while processing METHOD_ENTRY events.
When processing METHOD_ENTRY events, deterministic profilers have a stack
and don't need the whole call trace. They typically need the new frame
for the method that was just entered. (METHOD_ENTRY events don't have
methodIDs and are very fast).
Asking JVMPI for the last frame is a lot faster than asking for the whole
stack trace, hoever this can not be done if jvmpi truncates the last
frames.
If for some reason, you cannot fix this we can always switch to METHOD_ENTRY2
events, however, we are not sure that other vms support METHOD_ENTRY2 events
properly and we'll have to implement a special case for hotspot. (use
METHOD_ENTRY2 if hotspot is detected). We are trying to minimize special
cases and it would really help us if hotspot's jvmpi implementation
could work exactly like the classic jvmpi implementation when this
edge case occurs.
- backported by
-
JDK-2036439 method_exit events missing with method_entry2
-
- Resolved
-