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

[David Holmes]

Update looks good! Thanks Patricio!

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
>