Webrev for 6972759

Bill Pittore bill.pittore at oracle.com
Thu Jan 12 13:39:47 PST 2012

Thanks for the comment. I dug up a slightly dated (refers to SCCS ) 
coding convention document that recommends not to put bug IDs in the 
comments. I'll delete it.


On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote:
>  Looks OK. One comment, should we include the CR<id> in comment? I 
> remember it should not be there.
> --Yumin
> On 1/12/2012 12:24 PM, Bill Pittore wrote:
>> Hi David,
>>   Thanks for forwarding this to the SA list. I did run the nsk/jvmti 
>> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new 
>> failures with this change.
>> bill
>> On 1/12/2012 2:54 AM, David Holmes wrote:
>>> Hi Bill,
>>> I believe this should have gone out to the Serviceability list 
>>> (cc'ed) instead of, or perhaps as well as, the runtime list.
>>> The change looks okay to me in that is does what you described it 
>>> would. With JVMTI the proof-of-the-pudding is always in the testing 
>>> and I assume the various JVMTI test suites have been thoroughly 
>>> exercised ?
>>> Thanks,
>>> David
>>> On 11/01/2012 8:40 AM, Bill Pittore wrote:
>>>> Webrev for fix for 6972759 is at
>>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/
>>>> This bug has to do with single stepping after hitting an exception
>>>> breakpoint. The short story is that JVMTI maintains some thread state
>>>> information that was not updated correctly if a frame was popped 
>>>> off the
>>>> stack. When you pop a frame the exception state should go back to
>>>> _exception_detected=false. Otherwise when MethodExit event is sent at
>>>> some time in the future the 'was_popped_by_exception' flag will be set
>>>> and the agent receiving the event may not re-enable single stepping
>>>> properly. This problem will also affect ForceEarlyReturn code. 
>>>> Hacked up
>>>> a couple of existing nsk/jvmti tests to issue the necessary 
>>>> sequence of
>>>> JVMTI calls/events in order to test original bug and this fix.
>>>> bill

More information about the hotspot-runtime-dev mailing list