Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers

[serguei.spitsyn at oracle.com]

Hi David,

Thank you for the review!

On 11/27/13 1:04 AM, David Holmes wrote:
> Hi Serguei,
>
> This looks fine to me. Definitely low risk but not sure it is critical 
> enough for 8.

Thanks.
The priority is high and it impacts the tests stabilization as some 
other tests may potentially intermittently fail by the same reason.

>
> Minor nit:
>   _method_id = (jmethodID)NULL;
>
> It should never be necessary to cast NULL if assigning to a pointer type.

Let's consider this type cast as a hint for the code reader. :)
Also other places in the code use the same pattern, better keep it for 
consistency.

Thanks,
Serguei
>
> Thanks,
> David
>
> On 27/11/2013 11:34 AM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>>    https://bugs.openjdk.java.net/browse/JDK-8028126
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ 
>>
>>
>>
>> Summary:
>>    This is a fix for a possible race condition between the
>> VMOp_GetCurrentLocation
>>    reaching a safepoint and target debuggee thread exiting from Java
>> execution.
>>    The fix is to recheck the existence of the last Java frame at a
>> safepoint
>>    and clean the thread current location if the thread has been already
>> exited from Java.
>>
>>    I'm suggesting to fix this in hs25/JDK 8.
>>    It is important to fix as it is a P2 bug and the risk of fixing it is
>> low.
>>    But need reviewers to share opinions on this.
>>    I'll add the 8-critical-request label if reviewers agree with the 
>> above.
>>
>>
>> Testing:
>>    The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was
>> originally failed.
>>    In progress: nsk.jvmti, nsk.jdi, nsk.jdwp
>>
>>
>> Thanks,
>> Serguei