RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

[Jini George]

Please hold off on this review (since I might have some modifications to the changes).

 

Regds,

Jini.

 

From: Jini George 
Sent: Monday, April 25, 2016 2:29 PM
To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

 

Adding hotspot-runtime as well since this includes runtime changes.

 

Regards,

Jini.

 

From: Jini George 
Sent: Monday, April 25, 2016 1:23 PM
To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net
Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

 

Hello, 

Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

https://bugs.openjdk.java.net/browse/JDK-8043571

Webrev: 

http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/

 (Thanks to Dmitry for hosting this webrev).

The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934).

The issue was that  JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to:

1.      Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) 

2.      Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. 

With these changes the jdi tests which were failing with -Xcomp pass now. 

Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. 

Testing done: JPRT testsets: hotspot and SVC (with and without -Xcomp). 

I will be sending the changes for the JDK8 backport for this in a while, in  a separate webrev.

Thanks,

- Jini Susan George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160426/ca7dffd2/attachment-0001.html>