RFR: 8220724: TestBiasedLockRevocationEvents fails while matching revoke events to VMOperation events

[Robbin Ehn]

On 5/3/19 8:30 AM, David Holmes wrote:
> Update looks good! Thanks Patricio!

Ship it!

/Robbin

> 
> David
> -----
> 
> On 3/05/2019 3:38 pm, Patricio Chilano wrote:
>> Hi David,
>>
>> On 5/2/19 10:42 PM, David Holmes wrote:
>>> Hi Patricio,
>>>
>>> On 3/05/2019 4:48 am, Patricio Chilano wrote:
>>>> Hi,
>>>>
>>>> Could you review this small patch?
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8220724
>>>> http://cr.openjdk.java.net/~pchilanomate/8220724/v01/webrev/
>>>
>>> Basic approach is good. However as VM_BulkRevokeBias inherits from 
>>> VM_RevokeBias you don't need to duplicate all this _safepoint_id stuff:
>>>
>>>  578   uint64_t _safepoint_id;
>>>  587     , _safepoint_id(0) {}
>>>  598   uint64_t safepoint_id() const {
>>>  599     return _safepoint_id;
>>>  600   }
>> Done! Missed the inheritance.
>>
>>> Also please update copyright year.
>> Done.
>>
>> Here is the updated webrev:
>>
>> inc: http://cr.openjdk.java.net/~pchilanomate/8220724/v02/inc/webrev/
>> full: http://cr.openjdk.java.net/~pchilanomate/8220724/v02/webrev/
>>
>> Thanks for reviewing this change!
>>
>>
>> Thanks,
>> Patricio
>>
>>> Thanks,
>>> David
>>> ----
>>>
>>>
>>>> The subtest testRevocationSafepointIdCorrelation() in 
>>>> TestBiasedLockRevocationEvents.java fails intermittently because there could 
>>>> be a mismatch between the safepoint id recorded by the VMThread during the 
>>>> execution of a VM_RevokeBias or VM_BulkRevokeBias operation, and the one 
>>>> recorded by the JavaThread that requested the VM operation. I added a more 
>>>> detailed description of the problem in the comments of the bug.
>>>>
>>>> Testing tiers1-3 in mach5 and test TestBiasedLockRevocationEvents.java with 
>>>> flag -XX:+SafepointALot.
>>>>
>>>> Thanks!
>>>> Patricio
>>