Webrev for 6972759

[David Holmes]

On 13/01/2012 7:39 AM, Bill Pittore wrote:
> 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.

There are numerous places in the hotspot code where comments refer to a 
specific CR so I wouldn't be too concerned. Normally they serve as an 
external link for where to find out more info about why particular code 
was changed/used.

David

> thanks,
> bill
>
>
>
> 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
>>>>>
>>>>>
>>>
>>>
>
>