Webrev for 6972759
yumin.qi at oracle.com
yumin.qi at oracle.com
Thu Jan 12 12:34:08 PST 2012
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